2 апреля 2013 г., 0:36 пользователь "Артём Н." <artio...@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. Но вообще - без разницы, если будет обеспечивать то, что требуется. > > Я имел ввиду это: > > http://www.percona.com/software/percona-xtrabackup/downloads > Да я понял. Но, кажется, 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
