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

[Stanislav Vlasov <stanislav.v.v@gmail.com>]

31 марта 2013 г., 18:01 пользователь "Артём Н." <artiom14@yandex.ru> написал:
>>>>>> Тогда да, шаред сторадж. Можно обойтись DRBD, хотя лучше что-то более
>>>>>> приличное, конечно...
>>>> Дорого... Отдельные стораджи от того же HP. Из недублируемого - шасси.
>>> Да не. Аппаратные системы от HP мне никто не отдаст. :-)
>>> Из программного: только DRDB+OCFS?
>> Да. Наблюдаю удачное применение DRBD, но делал не я, так что про
>> грабли рассказать не могу.
>> OCFS можно заменить на GFS, но геморрою при этом будет значительно
>> больше, если не RHEL.
> RHEL/CentOS - сами по себе сплошные проблемы.

Не совсем. Пока задачи не выходят за рамки того, что есть в основном
репозитории - отличное решение, причём очень даже работающее.
А вот чуть в сторону - таки геморрой.

>> Да и в RHEL тоже геморрой по сравнению с OCFS.
> В чём?

Очень большое количество компонентов, требуемых для GFS2, взаимосвязь
которых хреново настраивается.
Под RHEL задача упрощается не слишком сильно. По-крайней мере, кластер
менее, чем на три машины делать уже точно не стоит.

> Так, насчёт СХД, первый вопрос.

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

Не совсем понял, кто на ком стоял, но ладно, разберёмся в процессе.
Хотя, если имелось ввиду, что много дисков должно быть на тех же
серверах, что и виртуалки, причём бекапы - туда же, то лучше всё-таки
немного подумать над реорганизацией. Бекапы должны лежать отдельно от
рабочих серверов. Желательно даже на расстоянии и в сейфе.
К тому же, при создании бекапов будет довольно приличная дисковая
нагрузка, процессор будет в основном в состоянии iowait, что повлияет
на работу виртуалок.

> 4. Коммутатор (говорят, что возможно найти лишний).

Для надёжности лучше два.

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

Нормальное ТЗ, вобщем-то.
К бекапам еще бы ленточек...

> Что хочу:
> 1. Организовать маленькое надёжное хранилище объёмом 2 Тб. Использовать для
> образов ВМ.

DRBD поверх раздела в 2Тб.
Как вариант - сделать этот раздел на стареньких серверах, объединить
их в DRBD и потом отдавать по iscsi весь том на оба сервера
виртуализации с одного из серверов.
При отказе - воспользоваться heartbeat для переключения ip-адреса
iscsi и master-slave в drbd.

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

С DRBD настолько на лету не выйдет, проверено. Только переконфигурация
томов, созданных поверх DRBD.

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

3 - может быть clvm (clustered lvm). Возможно, будет на несколько
процентов быстрее.

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

AoE пробовал - были проблемы с объединением сетевых карт. iscsi в этом
плане менее капризен.
Lustrefs - для бекапов пойдёт, для рабочего раздела - врядли.

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

Не нужен, но по iops оно значительно медленнее, чем iscsi.

> Про аппаратную виртуализацию, я так понимаю, придётся забыть? И Vt-d будет
> пропадать впустую.

А с какой целью оно надо?
Что на локальном разделе, что на удалённом - монопольно пробросить
аппаратный диск не выйдет, если его специально не выделяли для
виртуалки.
Устройство PCI - выйдет при любом диске, но при этом не получится
мигрировать виртуалку, в которую пробросил.

> С другой стороны, я ведь могу использовать
> паравиртуализованные ОС без потери производительности?

Как обычно, вобщем-то.

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

И? Причём тут именно заббикс?

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

Мдя... А что, кроме винды, ничего более приличного отмаршрутизировать
не нашлось?

>>> 2. Syslog надо чем-то анализировать. Придётся думать, чем "строить графики".
>> Э... Пока что по сислогу графиков не строил, чисто текстовыми
>> средствами анализировал.
> Я образно. :-) Logcheck и товарищей тоже надо настраивать на нестандартные события.

Всё равно настраивать. При любом мониторинге.

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

Скорее, первое, если они вообще его довели до конца.

>>> 1. rsnapshot подходит только для *nix-подобных, поскольку использует жёсткие
>>> ссылки (да, в NTFS тоже есть, но как-то не хочется).
>> Не совсем. Это на сторадже должен быть *nix. А на бекапируемом сервере - rsync.
>> К тому же, для винды есть виндовые средства, которые лучше спрашивать
>> там, где виндами пользуются больше.
> Всё-равно, всё должно сливаться в одно место. Лучше иметь нечто централизованное.
> Из виндовых средств они пользовались Norton Ghost.

Тогда - таки да, amanda. Но, насколько я помню, агента под винды надо
скачивать отдельно.

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

Гм... rsnapshot - средство создания копии дерева каталогов.
Организация хранения дерева каталогов такова, что можно увидеть копии
дерева на предыдущие моменты времени.
А то, как именно сделано копирование - уже другой вопрос.

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

Это критично в целом, так как у меня он ломался при интенсивной записи
на диск (параллельно несколько бекапов).

>>>> Делал снапшоты LVM и копировал диски целиком.
>>> Не вариант. В сети есть Windows машины, которые крайне желательно сохранять,
>>> причём это отдельные физические сервера, которые нельзя трогать (в плане, как
>>> были физическими, так и останутся).
>> Тогда - ищем виндовые средства.
> Так, агент Bacula?

Ну или агент amanda.

>> и потом копировать только изменившиеся места
> Используя rnapshot/rdiff-backup?

Как вариант. Ну или rsync --backup

>>>> Для БД - лучше что-то специализированное.
>>> Например? mysqldump? :-] А Bacula не справится с файлами БД (для mysql, mssql и
>>> pervasive sql)?|
>> БД файлами можно бекапить только в выключенном виде, проверено на innodb.
>> В крайнем случае - сделать таблицам lock, flush, сделать снапшот фс,
>> где база, разлочить таблицы и потом бекапить со снапшота. Не забываем
>> об удалении снапшота при любом завершении бекапа.
>  > Специализированное - имелось ввиду типа Percona Xtrabackup
> MySQL Enterprise Backup
> (InnoDB Hot Backup):
> Price   $5000 per server
> ? :-D

Ну... Если есть такие деньги...
Я имел ввиду это:
http://www.percona.com/software/percona-xtrabackup/downloads

Правда, сам пока что не пробовал.

>> но 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-интерфейс весьма приятный.
> Не сталкивались?

Нет, только слышал.

-- 
Stanislav