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

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




2 апреля 2013 г., 0:36 пользователь "Артём Н." <artiom14@yandex.ru> написал:
01.04.2013 08:30, Stanislav Vlasov пишет:
> Очень большое количество компонентов, требуемых для GFS2, взаимосвязь
> которых хреново настраивается.
> Под RHEL задача упрощается не слишком сильно. По-крайней мере, кластер
> менее, чем на три машины делать уже точно не стоит.
Понятно. Значит, стоит остановиться на OCFS2.

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

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

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

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

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

Мда... Извращение...

>> 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?

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

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

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

Угу, я тестировал как-то... Для текущих задач с iops порядка полутора тысяч на один сервер - не подойдёт.
В тестах на таком же железе и 2x1Гб сети выходило порядка нескольких сотен в пределе.
iscsi на этом же стенде упёрся в диски по iops.
Скорость чтения/записи отличалась на несколько процентов (оба явно упирались в сеть), так что тут разночтений нет.
 
>> С другой стороны, я ведь могу использовать
>> паравиртуализованные ОС без потери производительности?
> Как обычно, вобщем-то.
Т.е., вполне нормальный вариант (тогда сервера виртуализации будут на старых HP
Proliant)?

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

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

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

Хм... The most recent stable release is version 3.3.3, released on January 10, 2013.
Но вообще - без разницы, если будет обеспечивать то, что требуется.
 
Да я понял. Но, кажется, InnoDB бэкапить она не умеет во время работы?

It supports completely non-blocking backups of InnoDB, XtraDB, and HailDB storage engines. In addition, it can back up the following storage engines by briefly pausing writes at the end of the backup: MyISAM, Merge, and Archive, including partitioned tables, triggers, and database options.

Раз бекап non-blocking - таки он онлайн! :-)

>>> но 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?
      Или это лишено смысла?

Если параноик - достаточно raid5 под drbdb
 
   4. А что скажете насчёт OpenStack?

Ничего, я им не пользовался.


--
Stanislav

Reply to: