03.04.2013 07:24, Stanislav Vlasov пишет: >> Кстати, потому хотелось бы, чтобы кластер был виден, как одна машина, с >> одним >> IP: экран на виртуалке и проброс портов на внутренние виртуалки. > Э... Накой, собственно, один ип на всё? Можно и так, конечно. > Но смысл в локалке-то? Там адреса не ограничены. Смысл в том, чтобы внутри локалки кластер был виден, как одна машина и не возникало лишних вопросов.
> > > 3 - может быть clvm (clustered lvm). Возможно, будет на несколько > > > процентов быстрее. > > В смысле? Ведь cLVM тоже нужна кластерная ФС? Или вы про замену DRBD > на cLVM? > > Нет, clvm не требуется кластерная фс. И оно не заменяет drbd, а живёт > поверх. > > Просто это lvm, работающий в кластере, когда тома лвм доступны всем > узлам > кластера. > А управление блокировками на файлы/участки файлов чем реализуется? > Там нет файлов, это LVM. Блокировки - через кластерную инфраструктуру типа > corosync или что-то подобное. Я понял, потому и спрашиваю, должна ли поверх cLVM быть кластерная ФС? Завтра про него почитаю, если найду время. Насчёт corosync, я понял, что это "слой сообщений"... > > Угу, я тестировал как-то... Для текущих задач с iops порядка полутора > тысяч на > > один сервер - не подойдёт. > > В тестах на таком же железе и 2x1Гб сети выходило порядка нескольких > сотен в > > пределе. > > iscsi на этом же стенде упёрся в диски по iops. > > Скорость чтения/записи отличалась на несколько процентов (оба явно > упирались в > > сеть), так что тут разночтений нет. > Всё ясно. DRDB+iSCSI и не мудрить. > Ну да, если на сторадже не будет виртуалок. Думаю, не будет. > > > >> С другой стороны, я ведь могу использовать > > >> паравиртуализованные ОС без потери производительности? > > > Как обычно, вобщем-то. > > Т.е., вполне нормальный вариант (тогда сервера виртуализации будут > на > старых HP > > Proliant)? > > Только для линуксов. > Хм... А гипервизор только Xen? > Помнится, на старых компах, на которых собирался поднимать виртуалки, нет > аппаратной виртуализации. > Так что - таки да, только Xen. Можно lxc или openvz, но там уже не совсем > виртуалки. Кстати, да... Стоит подумать об OpenVZ, который, к тому же, здесь уже хвалили. > > Довели, наверное... Для чего тогда была новость, если в публичном > доступе > > этого нет? > > Судя по той ссылке - это было приглашение на работу программиста, > который > должен > > будет переделывать заббикс. > Мне показалось, что это презентация системы. :-) Ещё PDF-ка с похожим > содержанием где-то валялась. > Типа этого: > http://download.yandex.ru/company/experience/rit2008/highload_lapan.pdf > Хм... Значит, ту ссылку я пропустил. Тем не менее, в публичном доступе нет - > воспользоваться нельзя. > Разве что уговорить продать. :-) Особенно, учитывая то, что кроме меня, это никому не нужно. > > >>>> 2. rsnapshot всё-таки не распределённая система. Хотя, он и > использует > > rsync с > > >>>> бэкапом на сервер, я не помню возможно ли делать > > инкрементальные/декрементальные > > >>>> бэкапы таким образом (напрямую на сервер). > > >>> Не совсем понял вопроса. Накой делать копии сервера на сам > сервер? > > >> Инкрементальную копию удалённой машины на сервер. Возможно? > > >> Или нет? > > >> Или не стоит? > > > Гм... rsnapshot - средство создания копии дерева каталогов. > > > Организация хранения дерева каталогов такова, что можно увидеть > копии > > > дерева на предыдущие моменты времени. > > > А то, как именно сделано копирование - уже другой вопрос. > > Так тот же самый, с точки зрения преимуществ перед другими > системами. > > Хм... man rsync. > Почти 2000 строчек наводят уныние... :-) > Это разве много? :-) С учётом того, что сейчас у меня снова поломался rdiff-backup, я уже сомневаюсь. :-| И пришлось полностью удалить бэкап. Мало того, виртуалки не бэкапятся, потому что долго и места много. > > У rsnapshot можно и опции позадавать, хотя и по-умолчанию будет > > копироваться только изменившееся. Не помню, правда, будут ли > по-умолчанию > > считаться контрольные суммы остальных файлов или всё по размеру/времени > > изменения определяется. > Будет копироваться изменившийся файл, а не участок, так? > Не помню, как оно по-умолчанию. С опцией -c по сети однозначно будут > передаваться только изменившиеся блоки. Он по CRC сверяет? > Видимо, потому, что на предыдущей работе до покупки бекапа от Symantec было > довольно серьёзное рассмотрение доступных систем бекапов и аманда таки шла > наравне с симантеком, который выиграл только из-за требований от стороннего > софта про что-то там сертифицированное. > К сожалению, не помню, чем там не понравилась бакула, это было почти три года > назад. Но осадочек остался :-) А чем понравилась Amanda? Хотелось бы чуть подробнее? А недостатки? > Э... http://www.percona.com/software/percona-xtrabackup > Еще раз табличку пересмотрите. > Там разницы - параллельный бекап и т.п. > Оно, конечно, полезно, но далеко не всем надо. А, понял. Многопоточное копирование. Кстати, ещё бета. >>> Примерно так. Хотя под бекапы можно и не сетевую фс. Сделать два бекапных >>> сервера и всё. >> И прямо на них крутить бэкапилку? >> Охота её в ВМ засунуть... > Но смысл? По-хорошему, её надо вообще на отдельный сервер. На виртуалке разве хуже? Кстати, я совсем упустил из виду важный вопрос. А куда ставить ОС, которая будет работать на СХД? :-) Диски по 1 Тб. Терять целый диск под ОС слишком накладно... -- 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/515c7c63.2070...@yandex.ru
