LINUX.ORG.RU
ФорумAdmin

Помогите с выбором.

 ,


1

2

Приветствую всех И так есть у нас стенд из двух серверов... Хочу сделать на нем несколько виртуалок, но таким образом, что в случае если сломается один - все виртуалки можно было запустить на втором. То есть 100 избыточность. Все данные на виртуалках должны реплицироваться.. ну с какой-то переодичностью.. Посоветуйте на каком софте все это делать, если не считая тот факт, что в качестве хоста для виртуалок наверно буду использовать kvm.

з.ы. опыта не имею, поэтому и выцепил этот стенд чтобы поучится.

★★★

Просто иногда снимай снапшот всех виртуалок, и в случае чего поднимай всё на втором.

dada ★★★★★
()

Ну или drbd, или отказоустойчивый сторадж.

DALDON ★★★★★
()
Ответ на: комментарий от xsektorx

Можно линк?
Сам использую на нескольких серверах, проблем нет.
Пример: на дешевом http://www.hetzner.de/hosting/produkte_rootserver/ex10 17 виртуалок для разработчиков под RoR + jenkins + selenium, причем сверху на хосте 700 Gb pgsql (тоже тестовые среды разработчиков). Никому не тесно.

vadv ★★
()
Ответ на: комментарий от xsektorx

косячит опенвз.

Два чая этому пану. Недавно знакомый жаловался.

dada ★★★★★
()

Общий стораж с образами виртуалок и хосты с KVM. И никакой репликации не нужно.

Ximen ★★★★
()
Ответ на: комментарий от vadv

вот не помню. по своему опыту могу сказать, что косяки с фс есть. то есть, удалю я что-то, а он показывает меньше свободного места, чем должно быть. или сайты после того как забьётся всё место и будет очищено, до перезагрузки всё равно работать не хотят

xsektorx ★★★
()
Ответ на: комментарий от xsektorx

то есть, удалю я что-то, а он показывает меньше свободного места, чем должно быть.

Это фича. Стимулирует пользователей VPSок покупать больше свободного места. Та же фигня, кстати, с файловыми дискрипторами и памятью.

fjoe
()

proxmox. там есть и KVM и openvz. если есть дисковая полка - то там и храни виртуалки. если нет, можно глянуть в сторону drdb.

awesome
()

Либо так, либо так

  • drbd [+ pacemaker]
  • Отдельный сторадж
petav ★★★★★
()
Последнее исправление: petav (всего исправлений: 1)
Ответ на: комментарий от dada

Если этот вариант выберешь, то учти что снапшот очень сильно замедляет работу вирт.машины, вплоть до синего экрана в драйвере viostor, в случае win. И если это все на медленный носитель будет? то скорость еще больше просядет. Поэтому либо снапшот когда машина выключена, либо на отдельный жесткий диск (можно даже SSD).

petav ★★★★★
()
Ответ на: комментарий от petav

Если DRBD то позаботься о bonde нескольких интерфейсов между узлами.

petav ★★★★★
()
Ответ на: комментарий от Ximen

Общий стораж с образами виртуалок и хосты с KVM. И никакой репликации не нужно.

Общий сторадж становится единой точкой отказа; если он дохнет(/становится недотсупен, в общем случае), все вирт. ноды становятся неработоспособны. И где тут отказоустойчивость? Надёжность ситемы получается такой же, как у одиночного KVM-хоста, при ~двукратном возрастании сложности. Смысл городить такой огород, м?

Вот нормальный выход уже был озвучен - два хоста с репликацией вирт. машин (при не очень больших масштабах лучше, ИМХО, реализовывать репликацию средствами гостевых ОС - rsync,db replication и проч. Ну, можно и средствами LVM хоста, и снапшотами, конечно - по ситуации).

nbw ★★★
()

И, да, при возможности лучше, чтобы хосты были территориально разнесены - на случай прорыва канализации этажом выше, сумасшедшего пресонала, бомбо-штурмового удара и пр.

nbw ★★★
()
Ответ на: комментарий от nbw

Общий сторадж становится единой точкой отказа;

multipathing, RAID, redundant modules, LUN replication, link redundancy - и еще туева хуча вполне стандартно упакованных в любую стораджевую коробку начального уровня фичеров как раз для того и придуманы.

Надёжность ситемы получается такой же, как у одиночного KVM-хоста, при ~двукратном возрастании сложности. Смысл городить такой огород, м?

локальная репликация - огород не менее сложный. сравните кол-во телодвижений для настройки DRBD и кластерной фс, по сравнению с поднятием NFS сервера

Вот нормальный выход уже был озвучен - два хоста с репликацией вирт. машин (при не очень больших масштабах лучше, ИМХО, реализовывать репликацию средствами гостевых ОС - rsync,db replication и проч. Ну, можно и средствами LVM хоста, и снапшотами, конечно - по ситуации).

точно так же помрет как и при центральной СХД, если информация на одной из нод испорчена.

dyasny ★★★★★
()
Ответ на: комментарий от dyasny

multipathing, RAID, redundant modules, LUN replication, link redundancy

При отвале канала к узлу/форсмажоре и т.п. это не спасёт. Но, разумеется, каждому применению - свой инструмент, тут и спорить нечего. Каждую конфигурацию надо подбирать, исходя из общей целесообразности.

точно так же помрет как и при центральной СХД, если информация на одной из нод испорчена.

А вот уже для этого есть бэкапы (с раздельным хранением/дублированием) и прочие панацеи :D

nbw ★★★
()
Ответ на: комментарий от dyasny

сравните кол-во телодвижений для настройки DRBD и кластерной фс, по сравнению с поднятием NFS сервера

NFS тоже не везде применима. СУБД, например, и вообще приложения, порождающие высокий дисковый i/o, по гигабиту особо не погоняешь, да и по 10 иногда тоже.

nbw ★★★
()
Ответ на: комментарий от nbw

При отвале канала к узлу/форсмажоре и т.п. это не спасёт. Но, разумеется, каждому применению - свой инструмент, тут и спорить нечего. Каждую конфигурацию надо подбирать, исходя из общей целесообразности.

если упадет один канал - есть multipathing.

если весь ДЦ, то конечно все сложнее, и тут репликация между хостами в рамках одного ДЦ не поможет. А геокластеры строятся на более серьезных решениях - тут или gluster разворачивать надо, или решения на iFCP

dyasny ★★★★★
()
Ответ на: комментарий от dyasny

пацаны в нетаппе не знают, и вовсю ставят базы на NFS.

Не имел пока такой практики. Ну работает - и чудно, рад за них.

nbw ★★★
()
Ответ на: комментарий от nbw

Общий сторадж становится единой точкой отказа;

Смотря что он из себя представляет.

Вот нормальный выход уже был озвучен - два хоста с репликацией вирт. машин

Это не нормальный выход. Это редкостный велосипед, который, к тому же, хреново масштабируется.

Ximen ★★★★
()
Ответ на: комментарий от Ximen

Всё зависит от ситуации, скорее всего. Я пока не сталкивался с организациями, которые могут позволить себе реально отказоустойчивое хранилище. ТС, судя по всему, тоже не в IBM работает. А в крупном энтерпрайзе, конечно, и масштабы другие, и вытекающие из них решения.

nbw ★★★
()
Ответ на: комментарий от nbw

Всё зависит от ситуации, скорее всего.

Ну да, само собой.

Я пока не сталкивался с организациями, которые могут позволить себе реально отказоустойчивое хранилище.

Отказоустойчивое хранилище могут себе позволить те, кому нужна отказоустойчивость. Это достаточное требование. Но да, реально оно не часто требуется.

А в крупном энтерпрайзе, конечно, и масштабы другие, и вытекающие из них решения.

Это неправильное разделение - крупный/некрупный, энтерпрайз/неэнтерпрайз. Всё зависит от конкретных требований, именно они навязывают цену и решение. В одном некрупном и далеко неэнтерпрайзе заставили работать drbd-кластер. Херь, конечно, но отказоустойчивость появилась. Два хоста с виртуалками, два хоста с хранилищем - вот и вся цена вопроса.

Я это к чему - если речь заходит об отказоустойчивости и единой точке отказа, то лучше уж сразу закладывать правильную архитектуру. Чтобы не было потом мучительно больно.

Ximen ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.