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