29.03.2013 09:31, Stanislav Vlasov пишет:
> 29 марта 2013 г., 0:03 пользователь "Артём Н." <artio...@yandex.ru> написал:
>>>>>> Как сделать так, чтобы при выходе из строя одной машины *хранилища*, все
>>>>>> данные
>>>>>> (или наиболее критичные, которыми являются образы ВМ) оставались
>>>>>> доступны на второй?
>>>>> Тогда да, шаред сторадж. Можно обойтись DRBD, хотя лучше что-то более
>>>>> приличное, конечно...
>>>> Например?
>>> Дорого... Отдельные стораджи от того же HP. Из недублируемого - шасси.
>>> Но дорого.
>> Да не. Аппаратные системы от HP мне никто не отдаст. :-)
>> Из программного: только DRDB+OCFS?
> Да. Наблюдаю удачное применение DRBD, но делал не я, так что про
> грабли рассказать не могу.
> OCFS можно заменить на GFS, но геморрою при этом будет значительно
> больше, если не RHEL.
RHEL/CentOS - сами по себе сплошные проблемы.
> Да и в RHEL тоже геморрой по сравнению с OCFS.
В чём?
Так, насчёт СХД, первый вопрос.
Что имею:
1. Два сервера. В каждом 6 SATA на 1 Тб.
2. В них Core2 с Vt-d.
3. Пару особо старых одноюнитовых серверов без виртуализации ( к тому, что
предыдущие 2 - большие и диски перекрутить не получится, а ВМ где-то надо
запускать).
4. Коммутатор (говорят, что возможно найти лишний).
Что требуется:
1. Сохранять резервные копии с машин внутренней сети. Для начала возможно
ограничиться только настройками (думаю, что систему там смогут поставить). Под
это вполне хватит 8 Тб.
2. Иметь доступное хранилище для образов виртуальных машин. Под них за глаза
хватит 2 Тб.
Что хочу:
1. Организовать маленькое надёжное хранилище объёмом 2 Тб. Использовать для
образов ВМ.
2. Организовать ненадёжное хранилище объёмом 8 Тб. Использовать для резервных
копий и базы данных (в т.ч. Zabbix).
3. Иметь возможность менять конфигурацию СХД "на лету" (например, убрать часть
дисков из ненадёжного хранилища и создать ещё одно надёжное).
Как хочу реализовать (пока только задумки):
I. Надёжное хранилище.
1. Выделить 2 диска на каждом сервере под RAID-0.
2. Объединить в RAID-1, используя DRDB.
3. ФС - OCFS2.
II. Ненадёжное хранилище.
Тут задумок пока мало. Либо создать RAID0 и пробросить через iSCSI или
лучше
AoE. Либо использовать, например, Lustre.
А стоит ли вообще выдумывать со всякими "надёжными-ненадёжным хранилищами"?
Может, возможно ограничиться LustreFS (чтобы не плодить лишних наворотов)? Ведь
ей не нужен DRBD?
Я про неё, пока что, только начал читать.
Может, ей возможно явно указать, данные, которые требуют репликации и которые не
требуют вовсе, например (ы, и где реплицировать, a-la Spanner от google :-) )?
Про аппаратную виртуализацию, я так понимаю, придётся забыть? И Vt-d будет
пропадать впустую. С другой стороны, я ведь могу использовать
паравиртуализованные ОС без потери производительности?
>>>> И ведение "чёрного ящика".
>>> Хм... Что имелось ввиду
>> Имелось ввиду, что при неполадках где-либо (или при падении), нужно отследить
>> параметры, которые могут навести на причину проблем.
> Параметры в каком виде?
> Графики - обычно только показывают, когда стряслось.
Не только. Возможно посмотреть что было перед этим (например, кратковременно
пропадала связь или увеличилось количество ошибок интерфейса), а также на
графиках удобно наблюдать корреляции между разными переменными (те же пинги и
загрузка системы, к примеру).
>>> чем недостаточен для этого удалённый сислог?
>> 1. В Windows нет syslog.
> С виндами, конечно, хуже. Для них - отдельные средства.
Только агент и остаётся. Через винды нужно мониторить машины с QNX.
К тому же, там уже всё настроено (правда, чтобы всё нормально работало, для этой
замечательной "системы" пришлось написать свою утилиту ping :-) ).
>> 2. Syslog надо чем-то анализировать. Придётся думать, чем "строить графики".
> Э... Пока что по сислогу графиков не строил, чисто текстовыми
> средствами анализировал.
Я образно. :-) Logcheck и товарищей тоже надо настраивать на нестандартные
события.
>> 3. Syslog не записывает столько информации, сколько агент. Конечно, возможно
>> запустить разную мониторинговую приблуду, которая будет всё валить в лог, но
>> это
>> будет не очень удобно. Гораздо проще и эффективнее иметь единый агент.
> Не факт, что эффективнее... Впрочем, всякий SNMP никто не отменял.
Так одно другому не мешает. По SNMP собирались мониторить APC-шные ИБП. Через
Zabbix. Вроде даже адаптеры закупили, которые состояние ИБП через SNMP сливают.
Правда я только один адаптер видел. :-)
>>> У меня как раз была отдельная ВМ. Упёрлась в тогда локальный диск по
>>> количеству запросов в секунду и стала мешать соседям.
>>> Были установлены нагиос и какти, были натравлены на те же показатели,
>>> нагрузка стала на порядок меньше.
>> Ну я понял, что БД, всё-таки - крайне узкое место.
>> Но, насколько я понял, проблема с ней уже была решена Яндексом.
>
> Вначале рекомендую найти это решение. Лично я пока что видел только
> сообщение о его поиске.
Пока что, никаких результатов. Либо они его не предоставляли в общее
пользование, либо я плохо искал.
> К тому же, далеко не факт, что замена БД на фс уменьшит нагрузку.
Думаю, что уменьшит.
>>>> Ещё хочу систему рез. копирования.
>>>> Какую порекомендуете?
>>> Сильно зависит от того, как и что хотите копировать.
>>> Для файлов из линукса - rsnapshot неплох. У почтового сервера объём
>>> бекапа с историей за две недели составлял примерно 1.3 объёма от
>>> самого сервера. Да и у остальных серверов примерно также, так как
>>> менялись далеко не все файлы.
>> 1. rsnapshot подходит только для *nix-подобных, поскольку использует жёсткие
>> ссылки (да, в NTFS тоже есть, но как-то не хочется).
> Не совсем. Это на сторадже должен быть *nix. А на бекапируемом сервере -
> rsync.
> К тому же, для винды есть виндовые средства, которые лучше спрашивать
> там, где виндами пользуются больше.
Всё-равно, всё должно сливаться в одно место. Лучше иметь нечто
централизованное.
Из виндовых средств они пользовались Norton Ghost.
> Кстати, припоминаю, что amanda умела бекапить винды штатными виндовыми
> средствами.
> Возможно, путаю и там требовался бекапный агент
Про Amanda я давным давно читал.
> но что умела - точно.
Хотя, пакеты ещё есть в репозитории...
>> 2. rsnapshot всё-таки не распределённая система. Хотя, он и использует rsync
>> с
>> бэкапом на сервер, я не помню возможно ли делать
>> инкрементальные/декрементальные
>> бэкапы таким образом (напрямую на сервер).
> Не совсем понял вопроса. Накой делать копии сервера на сам сервер?
Инкрементальную копию удалённой машины на сервер. Возможно?
Или нет?
Или не стоит?
>> Кстати, у себя использую rdiff-backup. Тоже неплохая. Но для сети, мне
>> кажется,
>> плохо подойдёт.
> При большой нагрузке на сервер бекапов наблюдал, что база rdiff-backup
> ломается.
> Что касается сети - работало нормально.
У меня, бывает, ломается бэкап, когда перезагружается машина в процессе его
создания (или, особенно, при изменении скрипта рез. копирования и его проверке).
Полного бэкапа повторно делать не приходилось, но инкременты иногда приходится
удалять. Для локальной машины это, конечно, не критично...
>>> Делал снапшоты LVM и копировал диски целиком.
>> Не вариант. В сети есть Windows машины, которые крайне желательно сохранять,
>> причём это отдельные физические сервера, которые нельзя трогать (в плане, как
>> были физическими, так и останутся).
> Тогда - ищем виндовые средства.
Так, агент Bacula?
>> Кое-где завалялось малость BSD и немало QNX от 4.25 до 6.x. Хотя, видимо, их
>> сохранять не надо, поскольку особо там ничего не изменяется, да и сохранять
>> их
>> лучше локально (чтобы не иметь проблем, типа "вы туда свой софт поставили,
>> из-за
>> этого у нас вся сеть не работает").
> Один раз сделать dd диска, сохранить в N мест для надёжности
Это не катит с QNX.
После развёртывания образа, сделанного dd, на диск с отличной от исходного
геометрией, надо грузится в другом QNX и переписывать загрузчик на диске.
Но, думаю, что с теми машинами, для которых действительно надо было иметь бэкап,
проблема уже почти решена (через создание live CD, хранящего настройки, вместо
дискет, которыми до сих пор пользовались).
> и потом копировать только изменившиеся места
Используя rnapshot/rdiff-backup?
> Можно через scp, если rsync нельзя ставить.
Там не принципиально.
>>> Для БД - лучше что-то специализированное.
>> Например? mysqldump? :-] А Bacula не справится с файлами БД (для mysql,
>> mssql и
>> pervasive sql)?|
> БД файлами можно бекапить только в выключенном виде, проверено на innodb.
> В крайнем случае - сделать таблицам lock, flush, сделать снапшот фс,
> где база, разлочить таблицы и потом бекапить со снапшота. Не забываем
> об удалении снапшота при любом завершении бекапа.
> Специализированное - имелось ввиду типа Percona Xtrabackup
MySQL Enterprise Backup
(InnoDB Hot Backup):
Price $5000 per server
? :-D
> но mysqldump тож пойдёт :-)
Да, правда для MSSQL и Pervasive нужны отдельные инструменты...
Но бэкапы БД пока только в перспективе.
> Не помню, умеет ли bacula запускать внешние скрипты для создания
> бекапов. rsnapshot точно умеет
Насчёт бэкапов я в рассылке как-то спрашивал, порекомендовали, в том числе, и
такую штуку:
http://backuppc.sourceforge.net/
Пишут, что "BackupPC is a high-performance, enterprise-grade system for backing
up Linux and WinXX PCs and laptops to a server's disk."
И Web-интерфейс весьма приятный.
Не сталкивались?
--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5158257e.4040...@yandex.ru
