[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Виртуализация



 


2 апреля 2013 г., 23:27 пользователь "Артём Н." <artiom14@yandex.ru> написал:
02.04.2013 08:13, Stanislav Vlasov пишет:
>     >> 4. Коммутатор (говорят, что возможно найти лишний).
>     > Для надёжности лучше два.
>     Там, в принципе, несколько сетевых интерфейсов. Может, вообще, не нужен
>     коммутатор.
> Хм... Разве что сумеете обеспечить связь "каждый с каждым" без него, причём с
> двойным резервированием.
Мда, проще найти коммутатор. Просто раньше они, говорят, валялись кучкой, а
сейчас найти не получается.

shop.nag.ru в помощь. Правда, не знаю, насколько быстро.
 
> Мда...
Так а что делать? Там кластера особо никто не ждёт. Даже наоборот. Нужны бэкапы
и мониторилка (двух машин, которые под это выделили, достаточно за глаза).
Кластер я для себя хочу, ради обучения. И мне даже плюс, что ресурс сильно
ограничен, - думать заставляет и выбирать. 
Кстати, потому хотелось бы, чтобы кластер был виден, как одна машина, с одним
IP: экран на виртуалке и проброс портов на внутренние виртуалки.

Э... Накой, собственно, один ип на всё? Можно и так, конечно.
Но смысл в локалке-то? Там адреса не ограничены.
 
>     Я могу убрать два диска из Lustre и создать из них DRBD?
> Можно и так. Но опять же - в оффлайне.
Т.е., убрать с них данные (без особых мучений, естественно), перекинув на
остальные. Затем, убрать из LustreFS. После чего сделать из них том DRDB.

Ну да, вывести из эксплуатации и делать что хошь.
 
>     > 3 - может быть clvm (clustered lvm). Возможно, будет на несколько
>     > процентов быстрее.
>     В смысле? Ведь cLVM тоже нужна кластерная ФС? Или вы про замену DRBD на cLVM?
> Нет, clvm не требуется кластерная фс. И оно не заменяет drbd, а живёт поверх.
> Просто это lvm, работающий в кластере, когда тома лвм доступны всем узлам кластера.
А управление блокировками на файлы/участки файлов чем реализуется?

Там нет файлов, это LVM. Блокировки - через кластерную инфраструктуру типа corosync или что-то подобное.
 
>     > AoE пробовал - были проблемы с объединением сетевых карт. iscsi в этом
>     > плане менее капризен.
>     Какие проблемы?
> При бондинге двух сетевых карт и на клиенте и на сервере скрость передачи
> упёрлась в одну сетевую карту.
В смысле? Не очень понял. Работали обе сетевые карты, но максимальная скорость
каждой была ограничена скоростью самой низкоскоростной?
 
Там были две по гигабиту. Пробовались два варианта - только средствами AoE и бондинг.
В обоих случаях получался гигабит максимум. Дальше не разбирались.
 
> Угу, я тестировал как-то... Для текущих задач с iops порядка полутора тысяч на
> один сервер - не подойдёт.
> В тестах на таком же железе и 2x1Гб сети выходило порядка нескольких сотен в
> пределе.
> iscsi на этом же стенде упёрся в диски по iops.
> Скорость чтения/записи отличалась на несколько процентов (оба явно упирались в
> сеть), так что тут разночтений нет.
Всё ясно. DRDB+iSCSI и не мудрить.

Ну да, если на сторадже не будет виртуалок.
 
>     >> С другой стороны, я ведь могу использовать
>     >> паравиртуализованные ОС без потери производительности?
>     > Как обычно, вобщем-то.
>     Т.е., вполне нормальный вариант (тогда сервера виртуализации будут на старых HP
>     Proliant)?
> Только для линуксов.
Хм... А гипервизор только Xen?

Помнится, на старых компах, на которых собирался поднимать виртуалки, нет аппаратной виртуализации.
Так что - таки да, только Xen. Можно lxc или openvz, но там уже не совсем виртуалки.
 
>     Довели, наверное... Для чего тогда была новость, если в публичном доступе
>     этого нет?
> Судя по той ссылке - это было приглашение на работу программиста, который должен
> будет переделывать заббикс.
Мне показалось, что это презентация системы. :-) Ещё PDF-ка с похожим
содержанием где-то валялась.
Типа этого:
http://download.yandex.ru/company/experience/rit2008/highload_lapan.pdf

Хм... Значит, ту ссылку я пропустил. Тем не менее, в публичном доступе нет - воспользоваться нельзя.
Разве что уговорить продать.

>     >>>> 2. rsnapshot всё-таки не распределённая система. Хотя, он и использует
>     rsync с
>     >>>> бэкапом на сервер, я не помню возможно ли делать
>     инкрементальные/декрементальные
>     >>>> бэкапы таким образом (напрямую на сервер).
>     >>> Не совсем понял вопроса. Накой делать копии сервера на сам сервер?
>     >> Инкрементальную копию удалённой машины на сервер. Возможно?
>     >> Или нет?
>     >> Или не стоит?
>     > Гм... rsnapshot - средство создания копии дерева каталогов.
>     > Организация хранения дерева каталогов такова, что можно увидеть копии
>     > дерева на предыдущие моменты времени.
>     > А то, как именно сделано копирование - уже другой вопрос.
>     Так тот же самый, с точки зрения преимуществ перед другими системами.
> Хм... man rsync.
Почти 2000 строчек наводят уныние... :-)

Это разве много? :-)
 
> У rsnapshot можно и опции позадавать, хотя и по-умолчанию будет
> копироваться только изменившееся. Не помню, правда, будут ли по-умолчанию
> считаться контрольные суммы остальных файлов или всё по размеру/времени
> изменения определяется.
Будет копироваться изменившийся файл, а не участок, так?

Не помню, как оно по-умолчанию. С опцией -c по сети однозначно будут передаваться только изменившиеся блоки.
 
>     > Тогда - таки да, amanda. Но, насколько я помню, агента под винды надо
>     > скачивать отдельно.
>     Так а почему Amanda, а не Bacula?
>     Я не имею против неё ничего, кроме того, что я про неё почти ничего не знаю (о
>     Bacula хотя бы общее представление есть) и того, что, кажется, она не
>     поддерживается.
> Хм... The most recent stable release is version 3.3.3, released on January 10, 2013.
Понятно. В чём основные отличия от Bacula? Почему вы Amanda так рекомендуете?

Видимо, потому, что на предыдущей работе до покупки бекапа от Symantec было довольно серьёзное рассмотрение доступных систем бекапов и аманда таки шла наравне с симантеком, который выиграл только из-за требований от стороннего софта про что-то там сертифицированное.
К сожалению, не помню, чем там не понравилась бакула, это было почти три года назад. Но осадочек остался :-)
 
>     > Я имел ввиду это:
>     > http://www.percona.com/software/percona-xtrabackup/downloads
>     Да я понял. Но, кажется, InnoDB бэкапить она не умеет во время работы?
> It supports completely non-blocking backups of InnoDB, XtraDB, and HailDB
> storage engines. In addition, it can back up the following storage engines by
> briefly pausing writes at the end of the backup: MyISAM, Merge, and Archive,
> including partitioned tables, triggers, and database options.
> Раз бекап non-blocking - таки он онлайн! :-)
В чём тогда основная разница между платной и бесплатной (я смотрел, вроде бы, у
бесплатного не стояла галочка в графе "горячий бэкап")?

Э... http://www.percona.com/software/percona-xtrabackup
Еще раз табличку пересмотрите.
Там разницы - параллельный бекап и т.п.
Оно, конечно, полезно, но далеко не всем надо.

Кстати, есть некая "Zmanda Recovery Manager for MySQL".
Вообще, Amanda со товарищи - штука интересная.
Почему же Bacula больше "на слуху"?

Кому как ;-)
 
> Примерно так. Хотя под бекапы можно и не сетевую фс. Сделать два бекапных
> сервера и всё.
И прямо на них крутить бэкапилку?
Охота её в ВМ засунуть...

Но смысл? По-хорошему, её надо вообще на отдельный сервер.
 
>     Вопросы:
>        1. Крутить СУБД на тех же машинах, на которых реализована СХД - глупо?
> Может быть медленно. Хотя можно и приоритеты дискового ио расставить, конечно.

>        3. Лучше ли использовать RAID6, чем RAID0, в случае с RAID1 по DRDB?
>           Или это лишено смысла?
> Если параноик - достаточно raid5 под drbdb
А если параноик, но проблемы будут не моими, то RAID-0 с DRDB тоже вполне надёжен?

В принципе, на сложность уровень RAID не влияет, так что...

Зато влияет на объём и скорость. Правда, raid5 влияет не настолько, как raid1

--
Stanislav

Reply to: