Re: Виртуализация
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 Тб. Терять целый диск под ОС слишком накладно...
Reply to: