Re: Виртуализация
29 марта 2013 г., 0:03 пользователь "Артём Н." <artiom14@yandex.ru> написал:
>>>>> Как сделать так, чтобы при выходе из строя одной машины *хранилища*, все данные
>>>>> (или наиболее критичные, которыми являются образы ВМ) оставались доступны на второй?
>>>> Тогда да, шаред сторадж. Можно обойтись DRBD, хотя лучше что-то более
>>>> приличное, конечно...
>>> Например?
>> Дорого... Отдельные стораджи от того же HP. Из недублируемого - шасси.
>> Но дорого.
> Да не. Аппаратные системы от HP мне никто не отдаст. :-)
> Из программного: только DRDB+OCFS?
Да. Наблюдаю удачное применение DRBD, но делал не я, так что про
грабли рассказать не могу.
OCFS можно заменить на GFS, но геморрою при этом будет значительно
больше, если не RHEL.
Да и в RHEL тоже геморрой по сравнению с OCFS.
>>>> Если нужны показометры - таки да, zabbix. Хотя я как-то cacti
>>>> обходился, там почему-то меньше жрало.
>>> Желательны "показометры".
>> На мой взгляд, лучше не смешивать алерты и показометры.
>> Если показометры нужны для начальства - тем более.
> Для инженеров.
В зависимости от квалификации инженеров - либо таки заббикс, либо какти.
Если требуется, чтобы еще и не сильно жрало - лучше второе.
>>> И ведение "чёрного ящика".
>> Хм... Что имелось ввиду
> Имелось ввиду, что при неполадках где-либо (или при падении), нужно отследить
> параметры, которые могут навести на причину проблем.
Параметры в каком виде?
Графики - обычно только показывают, когда стряслось.
>> чем недостаточен для этого удалённый сислог?
> 1. В Windows нет syslog.
С виндами, конечно, хуже. Для них - отдельные средства.
> 2. Syslog надо чем-то анализировать. Придётся думать, чем "строить графики".
Э... Пока что по сислогу графиков не строил, чисто текстовыми
средствами анализировал.
> 3. Syslog не записывает столько информации, сколько агент. Конечно, возможно
> запустить разную мониторинговую приблуду, которая будет всё валить в лог, но это
> будет не очень удобно. Гораздо проще и эффективнее иметь единый агент.
Не факт, что эффективнее... Впрочем, всякий SNMP никто не отменял.
>> У меня как раз была отдельная ВМ. Упёрлась в тогда локальный диск по
>> количеству запросов в секунду и стала мешать соседям.
>> Были установлены нагиос и какти, были натравлены на те же показатели,
>> нагрузка стала на порядок меньше.
> Ну я понял, что БД, всё-таки - крайне узкое место.
> Но, насколько я понял, проблема с ней уже была решена Яндексом.
Вначале рекомендую найти это решение. Лично я пока что видел только
сообщение о его поиске.
К тому же, далеко не факт, что замена БД на фс уменьшит нагрузку.
>>> Ещё хочу систему рез. копирования.
>>> Какую порекомендуете?
>> Сильно зависит от того, как и что хотите копировать.
>> Для файлов из линукса - rsnapshot неплох. У почтового сервера объём
>> бекапа с историей за две недели составлял примерно 1.3 объёма от
>> самого сервера. Да и у остальных серверов примерно также, так как
>> менялись далеко не все файлы.
> 1. rsnapshot подходит только для *nix-подобных, поскольку использует жёсткие
> ссылки (да, в NTFS тоже есть, но как-то не хочется).
Не совсем. Это на сторадже должен быть *nix. А на бекапируемом сервере - rsync.
К тому же, для винды есть виндовые средства, которые лучше спрашивать
там, где виндами пользуются больше.
Кстати, припоминаю, что amanda умела бекапить винды штатными виндовыми
средствами.
Возможно, путаю и там требовался бекапный агент, но что умела - точно.
> 2. rsnapshot всё-таки не распределённая система. Хотя, он и использует rsync с
> бэкапом на сервер, я не помню возможно ли делать инкрементальные/декрементальные
> бэкапы таким образом (напрямую на сервер).
Не совсем понял вопроса. Накой делать копии сервера на сам сервер?
> Кстати, у себя использую rdiff-backup. Тоже неплохая. Но для сети, мне кажется,
> плохо подойдёт.
При большой нагрузке на сервер бекапов наблюдал, что база rdiff-backup ломается.
Что касается сети - работало нормально.
>> Делал снапшоты LVM и копировал диски целиком.
> Не вариант. В сети есть Windows машины, которые крайне желательно сохранять,
> причём это отдельные физические сервера, которые нельзя трогать (в плане, как
> были физическими, так и останутся).
Тогда - ищем виндовые средства.
> Кое-где завалялось малость BSD и немало QNX от 4.25 до 6.x. Хотя, видимо, их
> сохранять не надо, поскольку особо там ничего не изменяется, да и сохранять их
> лучше локально (чтобы не иметь проблем, типа "вы туда свой софт поставили, из-за
> этого у нас вся сеть не работает").
Один раз сделать dd диска, сохранить в N мест для надёжности и потом
копировать только изменившиеся места
Можно через scp, если rsync нельзя ставить.
>> Также очень даже неплоха bacula.
> Я думал как раз её использовать, но недавно написали следующее:
> "Bacula community много чего не умеет, в том числ дедупликацию, а без
> нее бэкапить виртуалки накладно."
> Что ещё не умеет?
Кто его знает... Давно ей пользовался...
>> Для БД - лучше что-то специализированное.
> Например? mysqldump? :-] А Bacula не справится с файлами БД (для mysql, mssql и
> pervasive sql)?|
БД файлами можно бекапить только в выключенном виде, проверено на innodb.
В крайнем случае - сделать таблицам lock, flush, сделать снапшот фс,
где база, разлочить таблицы и потом бекапить со снапшота. Не забываем
об удалении снапшота при любом завершении бекапа.
Специализированное - имелось ввиду типа Percona Xtrabackup, но
mysqldump тож пойдёт :-)
Не помню, умеет ли bacula запускать внешние скрипты для создания
бекапов. rsnapshot точно умеет
--
Stanislav
Reply to: