[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Виртуализация



01.04.2013 08:30, Stanislav Vlasov пишет:
> Очень большое количество компонентов, требуемых для GFS2, взаимосвязь
> которых хреново настраивается.
> Под RHEL задача упрощается не слишком сильно. По-крайней мере, кластер
> менее, чем на три машины делать уже точно не стоит.
Понятно. Значит, стоит остановиться на OCFS2.

>> Так, насчёт СХД, первый вопрос.
> 
>> Что имею:
>> 1. Два сервера. В каждом 6 SATA на 1 Тб.
>> 2. В них Core2 с Vt-d.
>> 3. Пару особо старых одноюнитовых серверов без виртуализации ( к тому, что
>> предыдущие 2 - большие и диски перекрутить не получится, а ВМ где-то надо
>> запускать).
> Не совсем понял, кто на ком стоял, но ладно, разберёмся в процессе.
2 сервера в каждом 6 x 1 Тб SATA. CPU с Vt-x (VT-d нет, сегодня смотрел).
В них 3 сетевых интерфейса. На них сейчас Fedora.
Их под СХД.

Помимо них, есть старые одноюнитовые HP ProLiant 2006 года с двумя сказями в 70
с чем-то Гб каждый. Сейчас на них RHEL. Они когда-то были резервом, но сейчас
настройки прикладного ПО на них неактуальны (как и железо).
Это из того, что есть в стойке. На них, естественно, VT нет. Там по два старых
ксеона на каждом.

Также, валяется ещё один HP с б`ольшим количеством SCSI дисков (но тоже
маленьких, наверное до 1 Тб, в сумме, не дотянет).
Коммутатор, пока что, найти не удалось.

> Хотя, если имелось ввиду, что много дисков должно быть на тех же
> серверах, что и виртуалки, причём бекапы - туда же, то лучше всё-таки
> немного подумать над реорганизацией. Бекапы должны лежать отдельно от
> рабочих серверов.
Я и хочу отдельно... Но процессоры на старых серверах намного хуже, чем на тех,
что под бэкапы (2 старых Xeon против Core2 Duo).

> Желательно даже на расстоянии и в сейфе.
Увы, нереально (реально разнести их по разным серверным, но слишком
проблематично). Они стоят в соседних стойках. Но, физическое разделение, в
принципе, не ко мне.

> К тому же, при создании бекапов будет довольно приличная дисковая
> нагрузка, процессор будет в основном в состоянии iowait, что повлияет
> на работу виртуалок.
Так ведь диски все давно с DMA (процессор будет ждать прерывания). Или всё-равно?

>> 4. Коммутатор (говорят, что возможно найти лишний).
> Для надёжности лучше два.
Там, в принципе, несколько сетевых интерфейсов. Может, вообще, не нужен коммутатор.

>> Что требуется:
>> 1. Сохранять резервные копии с машин внутренней сети. Для начала возможно
>> ограничиться только настройками (думаю, что систему там смогут поставить). Под
>> это вполне хватит 8 Тб.
>> 2. Иметь доступное хранилище для образов виртуальных машин. Под них за глаза
>> хватит 2 Тб.
> Нормальное ТЗ, вобщем-то.
> К бекапам еще бы ленточек...
Георгиевских или вы про стриммеры? :-)

>> Что хочу:
>> 1. Организовать маленькое надёжное хранилище объёмом 2 Тб. Использовать для
>> образов ВМ.
> DRBD поверх раздела в 2Тб.
> Как вариант - сделать этот раздел на стареньких серверах, объединить
> их в DRBD и потом отдавать по iscsi весь том на оба сервера
> виртуализации с одного из серверов.
На старых серверах нет места. Там SCSI не более, чем на 200-500 Гб (на тех, что
сейчас, вообще 100 с чем-то Гб).

> При отказе - воспользоваться heartbeat для переключения ip-адреса
> iscsi и master-slave в drbd.


>> 2. Организовать ненадёжное хранилище объёмом 8 Тб. Использовать для резервных
>> копий и базы данных (в т.ч. Zabbix).
>> 3. Иметь возможность менять конфигурацию СХД "на лету" (например, убрать часть
>> дисков из ненадёжного хранилища и создать ещё одно надёжное).
> С DRBD настолько на лету не выйдет, проверено. Только переконфигурация
> томов, созданных поверх DRBD.
А с Lustre?
Я могу убрать два диска из Lustre и создать из них DRBD?

>> Как хочу реализовать (пока только задумки):
>> I. Надёжное хранилище.
>>         1. Выделить 2 диска на каждом сервере под RAID-0.
>>         2. Объединить в RAID-1, используя DRDB.
>>         3. ФС - OCFS2.
> 3 - может быть clvm (clustered lvm). Возможно, будет на несколько
> процентов быстрее.
В смысле? Ведь cLVM тоже нужна кластерная ФС? Или вы про замену DRBD на cLVM?

> 
>> II. Ненадёжное хранилище.
>>         Тут задумок пока мало. Либо создать RAID0 и пробросить через iSCSI или лучше
>> AoE. Либо использовать, например, Lustre.
> 
> AoE пробовал - были проблемы с объединением сетевых карт. iscsi в этом
> плане менее капризен.
Какие проблемы?

> Lustrefs - для бекапов пойдёт, для рабочего раздела - врядли.
Вай?
По-идее, под бэкапы и хочу.
Но почему не под рабочий раздел?
Если бы оставить только LustreFS, конфигурация бы сильно упростилась...

>> А стоит ли вообще выдумывать со всякими "надёжными-ненадёжным хранилищами"?
>> Может, возможно ограничиться LustreFS (чтобы не плодить лишних наворотов)? Ведь
>> ей не нужен DRBD?
> Не нужен, но по iops оно значительно медленнее, чем iscsi.
Т.е., для виртуалок не подойдёт..?

>> Про аппаратную виртуализацию, я так понимаю, придётся забыть? И Vt-d будет
>> пропадать впустую.
> А с какой целью оно надо?
> Что на локальном разделе, что на удалённом - монопольно пробросить
> аппаратный диск не выйдет, если его специально не выделяли для
> виртуалки.
> Устройство PCI - выйдет при любом диске, но при этом не получится
> мигрировать виртуалку, в которую пробросил.
Я соврал. :-) Там только VT-x. Сегодня посмотрел.

>> С другой стороны, я ведь могу использовать
>> паравиртуализованные ОС без потери производительности?
> Как обычно, вобщем-то.
Т.е., вполне нормальный вариант (тогда сервера виртуализации будут на старых HP
Proliant)?

>>>> Имелось ввиду, что при неполадках где-либо (или при падении), нужно отследить
>>>> параметры, которые могут навести на причину проблем.
>>> Параметры в каком виде?
>>> Графики - обычно только показывают, когда стряслось.
>> Не только. Возможно посмотреть что было перед этим (например, кратковременно
>> пропадала связь или увеличилось количество ошибок интерфейса), а также на
>> графиках удобно наблюдать корреляции между разными переменными (те же пинги и
>> загрузка системы, к примеру).
> И? Причём тут именно заббикс?
При том, при чём любая система мониторинга.

>>>>> чем недостаточен для этого удалённый сислог?
>>>> 1. В Windows нет syslog.
>>> С виндами, конечно, хуже. Для них - отдельные средства.
>> Только агент и остаётся. Через винды нужно мониторить машины с QNX.
>> К тому же, там уже всё настроено (правда, чтобы всё нормально работало, для этой
>> замечательной "системы" пришлось написать свою утилиту ping :-) ).
> Мдя... А что, кроме винды, ничего более приличного отмаршрутизировать
> не нашлось?
Отмаршрути-что? :-)
Всё было до меня, естественно.
Windows 2000 (да, именно он) и суровые материалы проектирования, от которых ни
вправо, ни влево нельзя отступать (винда там откровенно бесполезная прослойка,
без которой, при грамотной организации системы, возможно обойтись, но говорить
об этом сейчас бессмысленно).

>>>> Ну я понял, что БД, всё-таки - крайне узкое место.
>>>> Но, насколько я понял, проблема с ней уже была решена Яндексом.
>>> Вначале рекомендую найти это решение. Лично я пока что видел только
>>> сообщение о его поиске.
>> Пока что, никаких результатов. Либо они его не предоставляли в общее
>> пользование, либо я плохо искал.
> Скорее, первое, если они вообще его довели до конца.
Довели, наверное... Для чего тогда была новость, если в публичном доступе этого нет?

>>>> 2. rsnapshot всё-таки не распределённая система. Хотя, он и использует rsync с
>>>> бэкапом на сервер, я не помню возможно ли делать инкрементальные/декрементальные
>>>> бэкапы таким образом (напрямую на сервер).
>>> Не совсем понял вопроса. Накой делать копии сервера на сам сервер?
>> Инкрементальную копию удалённой машины на сервер. Возможно?
>> Или нет?
>> Или не стоит?
> Гм... rsnapshot - средство создания копии дерева каталогов.
> Организация хранения дерева каталогов такова, что можно увидеть копии
> дерева на предыдущие моменты времени.
> А то, как именно сделано копирование - уже другой вопрос.
Так тот же самый, с точки зрения преимуществ перед другими системами.

>>>> Кстати, у себя использую rdiff-backup. Тоже неплохая. Но для сети, мне кажется,
>>>> плохо подойдёт.
>>> При большой нагрузке на сервер бекапов наблюдал, что база rdiff-backup ломается.
>>> Что касается сети - работало нормально.
>> У меня, бывает, ломается бэкап, когда перезагружается машина в процессе его
>> создания (или, особенно, при изменении скрипта рез. копирования и его проверке).
>> Полного бэкапа повторно делать не приходилось, но инкременты иногда приходится
>> удалять. Для локальной машины это, конечно, не критично...
> Это критично в целом, так как у меня он ломался при интенсивной записи
> на диск (параллельно несколько бекапов).
Понятно.

>>>>> Делал снапшоты LVM и копировал диски целиком.
>>>> Не вариант. В сети есть Windows машины, которые крайне желательно сохранять,
>>>> причём это отдельные физические сервера, которые нельзя трогать (в плане, как
>>>> были физическими, так и останутся).
>>> Тогда - ищем виндовые средства.
>> Так, агент Bacula?
> Ну или агент amanda.
...
>>>> 1. rsnapshot подходит только для *nix-подобных, поскольку использует жёсткие
>>>> ссылки (да, в NTFS тоже есть, но как-то не хочется).
>>> Не совсем. Это на сторадже должен быть *nix. А на бекапируемом сервере - rsync.
>>> К тому же, для винды есть виндовые средства, которые лучше спрашивать
>>> там, где виндами пользуются больше.
>> Всё-равно, всё должно сливаться в одно место. Лучше иметь нечто централизованное.
>> Из виндовых средств они пользовались Norton Ghost.
> Тогда - таки да, amanda. Но, насколько я помню, агента под винды надо
> скачивать отдельно.
Так а почему Amanda, а не Bacula?
Я не имею против неё ничего, кроме того, что я про неё почти ничего не знаю (о
Bacula хотя бы общее представление есть) и того, что, кажется, она не
поддерживается.

> Я имел ввиду это:
> http://www.percona.com/software/percona-xtrabackup/downloads
Да я понял. Но, кажется, InnoDB бэкапить она не умеет во время работы?

>>> но mysqldump тож пойдёт :-)
>> Да, правда для MSSQL и Pervasive нужны отдельные инструменты...
>> Но бэкапы БД пока только в перспективе.
> Лучше всё-таки заранее продумать. Систему-то в крайнем случае можно и
> заново поставить. А вот БД - хрен.
Я и продумываю. Просто, на данный момент, надо хоть СХД сделать.

>>> Не помню, умеет ли bacula запускать внешние скрипты для создания
>>> бекапов. rsnapshot точно умеет
>> Насчёт бэкапов я в рассылке как-то спрашивал, порекомендовали, в том числе, и
>> такую штуку:
>> http://backuppc.sourceforge.net/
>> Пишут, что "BackupPC is a high-performance, enterprise-grade system for backing
>> up Linux and WinXX PCs and laptops to a server's disk."
>> И Web-интерфейс весьма приятный.
>> Не сталкивались?
> Нет, только слышал.
И что говорят?

Т.е.:
   1. Под виртуалки RAID0 из двух дисков, объединённые по DRBD.
   2. Сделать LustreFS на 8 Тб под бэкапы.

Вопросы:
   1. Крутить СУБД на тех же машинах, на которых реализована СХД - глупо?
   2. А если падает один из дисков в LustreFS, что-то теряется?
   3. Лучше ли использовать RAID6, чем RAID0, в случае с RAID1 по DRDB?
      Или это лишено смысла?
   4. А что скажете насчёт OpenStack?


Reply to: