01.04.2013 08:30, Stanislav Vlasov пишет:
> Очень большое количество компонентов, требуемых для GFS2, взаимосвязьПонятно. Значит, стоит остановиться на OCFS2.
> которых хреново настраивается.
> Под RHEL задача упрощается не слишком сильно. По-крайней мере, кластер
> менее, чем на три машины делать уже точно не стоит.
> Хотя, если имелось ввиду, что много дисков должно быть на тех жеЯ и хочу отдельно... Но процессоры на старых серверах намного хуже, чем на тех,
> серверах, что и виртуалки, причём бекапы - туда же, то лучше всё-таки
> немного подумать над реорганизацией. Бекапы должны лежать отдельно от
> рабочих серверов.
что под бэкапы (2 старых Xeon против Core2 Duo).
> К тому же, при создании бекапов будет довольно приличная дисковая> нагрузка, процессор будет в основном в состоянии iowait, что повлияетТак ведь диски все давно с DMA (процессор будет ждать прерывания). Или всё-равно?
> на работу виртуалок.
>> 4. Коммутатор (говорят, что возможно найти лишний).Там, в принципе, несколько сетевых интерфейсов. Может, вообще, не нужен коммутатор.
> Для надёжности лучше два.
>> Что требуется:Георгиевских или вы про стриммеры? :-)
>> 1. Сохранять резервные копии с машин внутренней сети. Для начала возможно
>> ограничиться только настройками (думаю, что систему там смогут поставить). Под
>> это вполне хватит 8 Тб.
>> 2. Иметь доступное хранилище для образов виртуальных машин. Под них за глаза
>> хватит 2 Тб.
> Нормальное ТЗ, вобщем-то.
> К бекапам еще бы ленточек...
>> Что хочу:На старых серверах нет места. Там SCSI не более, чем на 200-500 Гб (на тех, что
>> 1. Организовать маленькое надёжное хранилище объёмом 2 Тб. Использовать для
>> образов ВМ.
> DRBD поверх раздела в 2Тб.
> Как вариант - сделать этот раздел на стареньких серверах, объединить
> их в DRBD и потом отдавать по iscsi весь том на оба сервера
> виртуализации с одного из серверов.
сейчас, вообще 100 с чем-то Гб).
>> 2. Организовать ненадёжное хранилище объёмом 8 Тб. Использовать для резервныхА с Lustre?
>> копий и базы данных (в т.ч. Zabbix).
>> 3. Иметь возможность менять конфигурацию СХД "на лету" (например, убрать часть
>> дисков из ненадёжного хранилища и создать ещё одно надёжное).
> С DRBD настолько на лету не выйдет, проверено. Только переконфигурация
> томов, созданных поверх DRBD.
Я могу убрать два диска из Lustre и создать из них DRBD?
>> Как хочу реализовать (пока только задумки):В смысле? Ведь cLVM тоже нужна кластерная ФС? Или вы про замену DRBD на cLVM?
>> I. Надёжное хранилище.
>> 1. Выделить 2 диска на каждом сервере под RAID-0.
>> 2. Объединить в RAID-1, используя DRDB.
>> 3. ФС - OCFS2.
> 3 - может быть clvm (clustered lvm). Возможно, будет на несколько
> процентов быстрее.
>Какие проблемы?
>> II. Ненадёжное хранилище.
>> Тут задумок пока мало. Либо создать RAID0 и пробросить через iSCSI или лучше
>> AoE. Либо использовать, например, Lustre.
>
> AoE пробовал - были проблемы с объединением сетевых карт. iscsi в этом
> плане менее капризен.
> Lustrefs - для бекапов пойдёт, для рабочего раздела - врядли.Вай?
По-идее, под бэкапы и хочу.
Но почему не под рабочий раздел?
Если бы оставить только LustreFS, конфигурация бы сильно упростилась...
>> А стоит ли вообще выдумывать со всякими "надёжными-ненадёжным хранилищами"?Т.е., для виртуалок не подойдёт..?
>> Может, возможно ограничиться LustreFS (чтобы не плодить лишних наворотов)? Ведь
>> ей не нужен DRBD?
> Не нужен, но по iops оно значительно медленнее, чем iscsi.
>> С другой стороны, я ведь могу использовать>> паравиртуализованные ОС без потери производительности?Т.е., вполне нормальный вариант (тогда сервера виртуализации будут на старых HP
> Как обычно, вобщем-то.
Proliant)?
>>>> Ну я понял, что БД, всё-таки - крайне узкое место.>>>> Но, насколько я понял, проблема с ней уже была решена Яндексом.Довели, наверное... Для чего тогда была новость, если в публичном доступе этого нет?
>>> Вначале рекомендую найти это решение. Лично я пока что видел только
>>> сообщение о его поиске.
>> Пока что, никаких результатов. Либо они его не предоставляли в общее
>> пользование, либо я плохо искал.
> Скорее, первое, если они вообще его довели до конца.
>>>> 2. rsnapshot всё-таки не распределённая система. Хотя, он и использует rsync сТак тот же самый, с точки зрения преимуществ перед другими системами.
>>>> бэкапом на сервер, я не помню возможно ли делать инкрементальные/декрементальные
>>>> бэкапы таким образом (напрямую на сервер).
>>> Не совсем понял вопроса. Накой делать копии сервера на сам сервер?
>> Инкрементальную копию удалённой машины на сервер. Возможно?
>> Или нет?
>> Или не стоит?
> Гм... rsnapshot - средство создания копии дерева каталогов.
> Организация хранения дерева каталогов такова, что можно увидеть копии
> дерева на предыдущие моменты времени.
> А то, как именно сделано копирование - уже другой вопрос.
>>>> 1. rsnapshot подходит только для *nix-подобных, поскольку использует жёсткие
>>>> ссылки (да, в NTFS тоже есть, но как-то не хочется).Так а почему Amanda, а не Bacula?
>>> Не совсем. Это на сторадже должен быть *nix. А на бекапируемом сервере - rsync.
>>> К тому же, для винды есть виндовые средства, которые лучше спрашивать
>>> там, где виндами пользуются больше.
>> Всё-равно, всё должно сливаться в одно место. Лучше иметь нечто централизованное.
>> Из виндовых средств они пользовались Norton Ghost.
> Тогда - таки да, amanda. Но, насколько я помню, агента под винды надо
> скачивать отдельно.
Я не имею против неё ничего, кроме того, что я про неё почти ничего не знаю (о
Bacula хотя бы общее представление есть) и того, что, кажется, она не
поддерживается.
Да я понял. Но, кажется, 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?