31 марта 2013 г., 18:01 пользователь "Артём Н." <artio...@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
