22.03.2013 08:30, Stanislav Vlasov пишет: > 21 марта 2013 г., 21:12 пользователь "Артём Н." <[email protected]> написал: >>>> Как сделать так, чтобы при выходе из строя одной машины *хранилища*, все >>>> данные >>>> (или наиболее критичные, которыми являются образы ВМ) оставались доступны >>>> на второй? >>> Тогда да, шаред сторадж. Можно обойтись 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)? -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
