Андрей Иванов написал замечательную статью про защиту данных (Вам чай с сахаром или руки с мылом помоете?).
Данная тема мне тоже интересна и я давно думал что-нибудь подобное написать.
Если вкратце, то есть несколько уровней защиты информации:
— аппаратный;
— программный;
— организационный.
Вообще говоря, деление довольно условное и позже я приведу решения, которые находятся на стыке нескольких уровней.
Аппаратный уровень
На аппаратном уровне какие-либо компоненты дублируются для исключения аппаратных сбоев. Самые распространенные решения этого уровня — это два блока питания и рейд-группы из нескольких жестких дисков (произвольного уровня, за исключением нулевого). Решения этого уровня всего лишь помогают снизить или исключить время простоя из-за аппаратных сбоев серверов. То есть:
— вышел из строя жесткий диск ~ рейд-контроллер сам перестроит рейд-группу без вмешательства системного администратора. Пользователи сервиса ничего не заметят.
— пользователь удалил файл либо запись в инф. системе ~ все, абзац. Аппаратный уровень тут бессилен.
Решения вроде VMware HA или VMware FT относятся целиком к этому уровню (особенно, HA).
Программный уровень
Здесь находятся программные средства, позволяющие продлить жизнь информации. Это всевозможные средства контроля целостности (например, журналы транзакций) и превентивный мониторинг (за исключением мониторинга железа).
Организационный уровень
Ну а здесь идет разграничение физического или программного доступа на несколько уровней. Я бы сюда отнес, например, предоставление доступа к ресурсам на основе групп Active Directory. На этом уровне определяется, кому и что нужно/можно делать.
Если вам нужно защитить ваши системы от программных сбоев, человеческих ошибок и других рисков, ничего лучше резервного копирования еще не придумано. Какая бы у вас супернадежная система не была, хоть XP Storageworks 24000, без бэкапов вы сильно рискуете. Конечно, вероятность сбоя ГОРАЗДО ниже, чем если данные лежат на простом файл-сервере. Но, подозреваю, СТОИМОСТЬ этих данных ГОРАЗДО выше.
Системы резервного копирования можно смело отнести к стыку программного и организационного уровней. Конечно, можно запросто настроить нужные ВАМ (ИТ-специалистам) бэкапы, но вот нужны ли они бизнесу/пользователям? Сможете ли вы восстановить из бэкапов информацию в нужном объеме и качестве за установленные сроки? Есть ли у вас план восстановления на случай системного сбоя? Хранится ли он на бумаге и доступен ли он в чрезвычайной ситуации? У вас есть ответы на эти вопросы?
Службы кластеров — стык аппаратного и программного уровней (как и прочие системы репликации). Распределенный кластер — стык всех трех уровней (как в принципе и любая другая катастрофо-устойчивая система).
Вопросы?
Боюсь показаться банальным, но выбору той или иной меры защиты информации (ну или комплекса мер) должна предшествовать некая оценка критичности той или иной информации. И сколько будет стоить эту инфу потерять или прожить без нее, скажем, час-два. А уже после выстраивать стратегию защиты. Имхо бОльшая проблема в том, что как раз ту самую оценку критичности мало кто проводит.
Системные адимнистраторы делятся на тех, кто не делает бэкапы, и тех, кто теперь делает
Соглашусь с тобой, Павел. Зачастую не имеет смысла городить огород ради защиты MP3-файлов пользователей 😉
Андрей, самый прикол в том, что в самом распоследнем вшивом NAS есть поддержка рейд. И на форумах, в т.ч. тринити постоянно возникают вопросы о том, как сделать за 3 копейки ДОМАШИЙ NAS с ШЕСТЫМ, сука, рейдом. И это вместо того, чтобы взять два этих диска и писать на них бэкапы.
Они еще про СПАРЕ диски забыли
:)))
А все от непонимания.
Могу привести другой пример. Допустим, у нас есть СУБД. Универсальные рекомендации следующие:
— разнести файлы баз и логов по разным шпинделям (рейдгруппам);
— R5/R10 под базы;
— R1 под логи.
Однако, если контора МОЖЕТ прожить без работающей СУБД определенное время, и выполняются определенные условия, то под базы я бы предложил использовать НУЛЕВОЙ рейд. 🙂
Вариант разнесения базы и логов работает при очень большом числе дисков, чаще всего имеет смысл объединять диски в один массив.
В нулевом рейде смысла нет, т.к. выигрыш на малом числе дисков будет невелик относительно зеркала или десятки, а на большом числе дисков — я не могу представить такую задачу, чтобы и много дисков и день простоя 🙂
С теоретической точки зрения, выигрыш при использовании R0 может иметь смысл.
Допустим у нас есть N жестких дисков, каждый из которых дает M операций ввода/вывода в секунду (или IOPS).
С точки зрения голой теории справедливо следующее:
Тип рейда Read IOPS Write IOPS
R0 N*M N*M
R1/R10 N*M N*M/2
R5 N*M N*M/4
R6 N*M N*M/6
Для раздела с логами характерны операции на запись, кроме того, журналы транзакций очень важны, поэтому для них R1/R10 без вариантов.
Для раздела с файлами баз данных все сложнее. Если там преимущественно операции чтения, то подойдет любой рейд (и поэтому часто рекомендуют R5 для транзакционных БД). А вот если характер нагрузки несколько смещен в сторону записи…
Тогда только R1/R10.
Давайте разберем пример 🙂
У нас есть идеальные диски, которые дают по 200IOPS. Нам нужно получить систему, которая может держать до 3000 чтений в секунду или до 1000 записей в секунду (про одновременный характер нагрузки для простоты не говорим).
Посчитаем количество дисков для R10 и для R5…
R5: чтение — 3000/200=15 дисков, запись — 1000*4/200=20 дисков (пенальти при использовании R5 на запись — ранее на блоге писал).
R10: чтение — 3000/200=15 дисков, запись 1000*2/200=10 дисков.
Итого, на R10 для указанной нагрузки нам надо 15 дисков, для R5 — 20. Неожиданно, правда?
Ничего неожиданного 🙂
Итак, у нас БД с профилем 50:50 и 8 винтов в 10ке
Идет чтение из базы: доступно 8*200 iops
Идет запись в базу: и на лог и на бд доступно 4*200 iops поочередно
Меняем разбивку, делаем две десятки по 4 винта:
Идет чтение из базы: доступно 4*200 iops
Идет запись в базу: на лог доступно 2*200 iops по завершению операции — на запись — 2*200 iops
😉
То есть вы оба считаете, что если у вас будет сотни полторы workers, то их суммарный IOPS будет с диска 200? Потренируйтесь на IOmeter!
🙂
Я же сказал, возьмем идеальные диски. Естественно, реальный IOPS гораздо ниже.
«Оптимисты закладывают по 110 IOPS на FC-диск, пессимисты по 70» (© 2009, HP Accelerated SAN Essentials, Владимир Стригин).
По поводу записи в базу. В общем случае ты, diz, конечно, прав. Вот только при наличии оперативки наиболее используемые БД лежат в ней и лишь время от времени записывают изменения в базы из лога.
Соответственно, если 400 IOPS — это максимальные и редко достижимые показатели для нашей СУБД, то в производительность на запись в базу мы не упираемся.
Прикольная ссылка про белую серверную лисичку:
http://ms-virtual.blogspot.com/2009/04/blog-post_09.html.
А вы уже делаете бэкапы?