LINUX.ORG.RU
решено ФорумAdmin

Сервер без RAID, но с rsnapshot


3

2

Добрый день друзья!

Подскажите по сабжу: представим себе хост ESXi с UPS, пусть на нём работает один HDD, с n виртуальных машин. Сами машины в виде экспорта лежат на стороннем сервере для backup. Изменяемые данные которые генерируются внутри виртуальных машин ежедневно забираются rsnapshotом на удалённый сервер и лежат там в течении месяца (ротация средствами rsnapshot + и его же инкремент).

При выходе из строя HDD на ESXi простой в течении рабочего дня допустим. - Если он сдохнет резко, и мне придётся подняться с экспортных машин и накатить данные суточной давности - это устроит вполне.

Чем опасна такая схема? Насколько велик шанс того, что HDD который крутит n машин когда начнёт сыпаться, повалит _частично_ данные в них, и rsnapshot будет забирать битые данные, а я ничего и не узнаю? - Я думаю такое мало вероятно, и если HDD начнёт сбоить, приложения в VM начнут себя неадекватно вести, и я об этом сразу же догадаюсь по сбоям в работе.

Насколько опасно без RAID обходиться, если применять rsnapshot?

P.S. железный RAID тоже вызывает некоторые вопросы при всех своих плюсах... По-этому и интересуюсь.

★★★★★

Последнее исправление: DALDON (всего исправлений: 1)
Ответ на: комментарий от petav

Это да. Ну в режиме slave/master с sync опцией, это выходит что: оно запишет на первую ноду, отдаст по Сети на вторую, запишет туда, получит успешный ответ, и только тогда отрапортует о том что запись закончена. - Async сыкатно пользовать...

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

Тут уже двояко выходит, или платного ПО купить которое обладает эффективными алгоритмами backup, компрессия и всё прочее например гранулярное восстановление, мышкотыркательный интерфейс. Или купить дорогое железо которое будет компенсировать недостатки OpenSource ПО.

Ну а что касается меня, могу сказать следующее: асилил я rdiff-backup, очень интересная штука доложу я Вам.

Пока сценарий с ESXi выглядит след. образом:

  • shh key based auth
  • suspend a VM (in a my case it has a 16gb data storage)
  • mount ESXi via sshfs on a backup server
  • start rdiff-backup. It takes over 35 mins via 10/100 mb/sec network
  • start a VM

И обратный подъём на такой сетке занимает теже 40 минут, на 16гб машинку.

Итого у меня получилось:

  • Мониторить SMART любого диска на ESXi
  • Мониторить SMART с 3ware контроллера с BBU
  • Забирать ГАРАНТИРОВАННО консистентную машинку 16 гб за 40 минут её простоя. - При этом при восстановлении даже горячей перезагрузки не будет, ибо я RAM также забираю консистентную. - Время простоя можно уменьшить если перейти на гигабитную сетку. Раза эдак в два-три.
  • Восстанавливать машинку на любое инкрементное состояние

И ещё petav рассказал мне много интересных вещей, например алгоритм снятия backup машинки через drbd, весьма не плох на мой взгляд.

P.S. в моей ситуации простой машинки по часу в ночное время вполне допустим. Но на больших машинах можно уже внутри самой машинки забирать данные через snapshot и rdiff - т.о. простой будет минимальный. Но это уже поболее возни, т.к. придётся делать всё внутри каждой VM и подниматься потом в два этапа.

DALDON ★★★★★
() автор топика
Последнее исправление: DALDON (всего исправлений: 1)
Ответ на: комментарий от DALDON

Что же касается моего решения про RAID доложу следующее:

Как показывает результат S.M.A.R.T. с полудохлых дисков - он таки может адекватно предсказывать смерть.

Исходя из этого решил так: не критичные VM, держать без RAID, критичные с RAID, благо контроллер имеется.

Спасибо ещё раз за rdiff-backup!

[/thread]

DALDON ★★★★★
() автор топика
Последнее исправление: DALDON (всего исправлений: 2)
Ответ на: комментарий от DALDON

Тут уже двояко выходит, или платного ПО купить которое обладает эффективными алгоритмами backup, компрессия и всё прочее например гранулярное восстановление, мышкотыркательный интерфейс.

Для кого-то, в том числе для меня, мышкотыкателный интрефейс это больше недостаток, чем достоинство.

Или купить дорогое железо которое будет компенсировать недостатки OpenSource ПО.

Не буду спорить. Соизмеримое нужно сравнивать.

И обратный подъём на такой сетке занимает теже 40 минут, на 16гб машинку.

У меня по такой же сети бэкап 50Гб, происходит за 12 минут.

Забирать ГАРАНТИРОВАННО консистентную машинку

suspend a VM. )))

критичные с RAID, благо контроллер имеется

если имеется?! Контроллеры за копейки (fake raid) больше вреда принесут чем пользы.

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

У меня по такой же сети бэкап 50Гб, происходит за 12 минут.

Это видимо Bacula делает инкремент с такой скоростью? Иначе я думаю 14 c лишним мегабайт в секунду просто физически не пролезут в 10 мегабайтный канал. rdiff, вот делает дольше, что в первый раз, что во второй разницы по времени практически нет. Но во второй раз CPU backup машины считает много больше.

suspend a VM. )))

Ну да. Если подниматься потом на ESXi, то машина ведёт себя так, словно и не выключалась вовсе.

если имеется?!

Да, с большим объёмом памяти и BBU модулем, всё хорошо. fakeraid не поддерживается в ESXi.

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

Это видимо Bacula делает инкремент с такой скоростью

Нет, не инкремент. А алгоритмы бакула

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