01.04.2013 08:30, Stanislav Vlasov пишет: > Очень большое количество компонентов, требуемых для GFS2, взаимосвязь > которых хреново настраивается. > Под RHEL задача упрощается не слишком сильно. По-крайней мере, кластер > менее, чем на три машины делать уже точно не стоит. Понятно. Значит, стоит остановиться на OCFS2.
>> Так, насчёт СХД, первый вопрос. > >> Что имею: >> 1. Два сервера. В каждом 6 SATA на 1 Тб. >> 2. В них Core2 с Vt-d. >> 3. Пару особо старых одноюнитовых серверов без виртуализации ( к тому, что >> предыдущие 2 - большие и диски перекрутить не получится, а ВМ где-то надо >> запускать). > Не совсем понял, кто на ком стоял, но ладно, разберёмся в процессе. 2 сервера в каждом 6 x 1 Тб SATA. CPU с Vt-x (VT-d нет, сегодня смотрел). В них 3 сетевых интерфейса. На них сейчас Fedora. Их под СХД. Помимо них, есть старые одноюнитовые HP ProLiant 2006 года с двумя сказями в 70 с чем-то Гб каждый. Сейчас на них RHEL. Они когда-то были резервом, но сейчас настройки прикладного ПО на них неактуальны (как и железо). Это из того, что есть в стойке. На них, естественно, VT нет. Там по два старых ксеона на каждом. Также, валяется ещё один HP с б`ольшим количеством SCSI дисков (но тоже маленьких, наверное до 1 Тб, в сумме, не дотянет). Коммутатор, пока что, найти не удалось. > Хотя, если имелось ввиду, что много дисков должно быть на тех же > серверах, что и виртуалки, причём бекапы - туда же, то лучше всё-таки > немного подумать над реорганизацией. Бекапы должны лежать отдельно от > рабочих серверов. Я и хочу отдельно... Но процессоры на старых серверах намного хуже, чем на тех, что под бэкапы (2 старых Xeon против Core2 Duo). > Желательно даже на расстоянии и в сейфе. Увы, нереально (реально разнести их по разным серверным, но слишком проблематично). Они стоят в соседних стойках. Но, физическое разделение, в принципе, не ко мне. > К тому же, при создании бекапов будет довольно приличная дисковая > нагрузка, процессор будет в основном в состоянии iowait, что повлияет > на работу виртуалок. Так ведь диски все давно с DMA (процессор будет ждать прерывания). Или всё-равно? >> 4. Коммутатор (говорят, что возможно найти лишний). > Для надёжности лучше два. Там, в принципе, несколько сетевых интерфейсов. Может, вообще, не нужен коммутатор. >> Что требуется: >> 1. Сохранять резервные копии с машин внутренней сети. Для начала возможно >> ограничиться только настройками (думаю, что систему там смогут поставить). >> Под >> это вполне хватит 8 Тб. >> 2. Иметь доступное хранилище для образов виртуальных машин. Под них за глаза >> хватит 2 Тб. > Нормальное ТЗ, вобщем-то. > К бекапам еще бы ленточек... Георгиевских или вы про стриммеры? :-) >> Что хочу: >> 1. Организовать маленькое надёжное хранилище объёмом 2 Тб. Использовать для >> образов ВМ. > DRBD поверх раздела в 2Тб. > Как вариант - сделать этот раздел на стареньких серверах, объединить > их в DRBD и потом отдавать по iscsi весь том на оба сервера > виртуализации с одного из серверов. На старых серверах нет места. Там SCSI не более, чем на 200-500 Гб (на тех, что сейчас, вообще 100 с чем-то Гб). > При отказе - воспользоваться heartbeat для переключения ip-адреса > iscsi и master-slave в drbd. >> 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? > >> II. Ненадёжное хранилище. >> Тут задумок пока мало. Либо создать RAID0 и пробросить через iSCSI >> или лучше >> AoE. Либо использовать, например, Lustre. > > AoE пробовал - были проблемы с объединением сетевых карт. iscsi в этом > плане менее капризен. Какие проблемы? > Lustrefs - для бекапов пойдёт, для рабочего раздела - врядли. Вай? По-идее, под бэкапы и хочу. Но почему не под рабочий раздел? Если бы оставить только LustreFS, конфигурация бы сильно упростилась... >> А стоит ли вообще выдумывать со всякими "надёжными-ненадёжным хранилищами"? >> Может, возможно ограничиться LustreFS (чтобы не плодить лишних наворотов)? >> Ведь >> ей не нужен DRBD? > Не нужен, но по iops оно значительно медленнее, чем iscsi. Т.е., для виртуалок не подойдёт..? >> Про аппаратную виртуализацию, я так понимаю, придётся забыть? И Vt-d будет >> пропадать впустую. > А с какой целью оно надо? > Что на локальном разделе, что на удалённом - монопольно пробросить > аппаратный диск не выйдет, если его специально не выделяли для > виртуалки. > Устройство PCI - выйдет при любом диске, но при этом не получится > мигрировать виртуалку, в которую пробросил. Я соврал. :-) Там только VT-x. Сегодня посмотрел. >> С другой стороны, я ведь могу использовать >> паравиртуализованные ОС без потери производительности? > Как обычно, вобщем-то. Т.е., вполне нормальный вариант (тогда сервера виртуализации будут на старых HP Proliant)? >>>> Имелось ввиду, что при неполадках где-либо (или при падении), нужно >>>> отследить >>>> параметры, которые могут навести на причину проблем. >>> Параметры в каком виде? >>> Графики - обычно только показывают, когда стряслось. >> Не только. Возможно посмотреть что было перед этим (например, кратковременно >> пропадала связь или увеличилось количество ошибок интерфейса), а также на >> графиках удобно наблюдать корреляции между разными переменными (те же пинги и >> загрузка системы, к примеру). > И? Причём тут именно заббикс? При том, при чём любая система мониторинга. >>>>> чем недостаточен для этого удалённый сислог? >>>> 1. В Windows нет syslog. >>> С виндами, конечно, хуже. Для них - отдельные средства. >> Только агент и остаётся. Через винды нужно мониторить машины с QNX. >> К тому же, там уже всё настроено (правда, чтобы всё нормально работало, для >> этой >> замечательной "системы" пришлось написать свою утилиту ping :-) ). > Мдя... А что, кроме винды, ничего более приличного отмаршрутизировать > не нашлось? Отмаршрути-что? :-) Всё было до меня, естественно. Windows 2000 (да, именно он) и суровые материалы проектирования, от которых ни вправо, ни влево нельзя отступать (винда там откровенно бесполезная прослойка, без которой, при грамотной организации системы, возможно обойтись, но говорить об этом сейчас бессмысленно). >>>> Ну я понял, что БД, всё-таки - крайне узкое место. >>>> Но, насколько я понял, проблема с ней уже была решена Яндексом. >>> Вначале рекомендую найти это решение. Лично я пока что видел только >>> сообщение о его поиске. >> Пока что, никаких результатов. Либо они его не предоставляли в общее >> пользование, либо я плохо искал. > Скорее, первое, если они вообще его довели до конца. Довели, наверное... Для чего тогда была новость, если в публичном доступе этого нет? >>>> 2. rsnapshot всё-таки не распределённая система. Хотя, он и использует >>>> rsync с >>>> бэкапом на сервер, я не помню возможно ли делать >>>> инкрементальные/декрементальные >>>> бэкапы таким образом (напрямую на сервер). >>> Не совсем понял вопроса. Накой делать копии сервера на сам сервер? >> Инкрементальную копию удалённой машины на сервер. Возможно? >> Или нет? >> Или не стоит? > Гм... rsnapshot - средство создания копии дерева каталогов. > Организация хранения дерева каталогов такова, что можно увидеть копии > дерева на предыдущие моменты времени. > А то, как именно сделано копирование - уже другой вопрос. Так тот же самый, с точки зрения преимуществ перед другими системами. >>>> Кстати, у себя использую rdiff-backup. Тоже неплохая. Но для сети, мне >>>> кажется, >>>> плохо подойдёт. >>> При большой нагрузке на сервер бекапов наблюдал, что база rdiff-backup >>> ломается. >>> Что касается сети - работало нормально. >> У меня, бывает, ломается бэкап, когда перезагружается машина в процессе его >> создания (или, особенно, при изменении скрипта рез. копирования и его >> проверке). >> Полного бэкапа повторно делать не приходилось, но инкременты иногда >> приходится >> удалять. Для локальной машины это, конечно, не критично... > Это критично в целом, так как у меня он ломался при интенсивной записи > на диск (параллельно несколько бекапов). Понятно. >>>>> Делал снапшоты LVM и копировал диски целиком. >>>> Не вариант. В сети есть Windows машины, которые крайне желательно >>>> сохранять, >>>> причём это отдельные физические сервера, которые нельзя трогать (в плане, >>>> как >>>> были физическими, так и останутся). >>> Тогда - ищем виндовые средства. >> Так, агент Bacula? > Ну или агент amanda. ... >>>> 1. rsnapshot подходит только для *nix-подобных, поскольку использует >>>> жёсткие >>>> ссылки (да, в NTFS тоже есть, но как-то не хочется). >>> Не совсем. Это на сторадже должен быть *nix. А на бекапируемом сервере - >>> rsync. >>> К тому же, для винды есть виндовые средства, которые лучше спрашивать >>> там, где виндами пользуются больше. >> Всё-равно, всё должно сливаться в одно место. Лучше иметь нечто >> централизованное. >> Из виндовых средств они пользовались Norton Ghost. > Тогда - таки да, amanda. Но, насколько я помню, агента под винды надо > скачивать отдельно. Так а почему Amanda, а не Bacula? Я не имею против неё ничего, кроме того, что я про неё почти ничего не знаю (о Bacula хотя бы общее представление есть) и того, что, кажется, она не поддерживается. > Я имел ввиду это: > http://www.percona.com/software/percona-xtrabackup/downloads Да я понял. Но, кажется, 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? -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5159d3b4.40...@yandex.ru