Заметка про защиту данных

Андрей Иванов написал замечательную статью про защиту данных (Вам чай с сахаром или руки с мылом помоете?).
Данная тема мне тоже интересна и я давно думал что-нибудь подобное написать.
Если вкратце, то есть несколько уровней защиты информации:
– аппаратный;
– программный;
– организационный.
Вообще говоря, деление довольно условное и позже я приведу решения, которые находятся на стыке нескольких уровней.

Аппаратный уровень
На аппаратном уровне какие-либо компоненты дублируются для исключения аппаратных сбоев. Самые распространенные решения этого уровня – это два блока питания и рейд-группы из нескольких жестких дисков (произвольного уровня, за исключением нулевого). Решения этого уровня всего лишь помогают снизить или исключить время простоя из-за аппаратных сбоев серверов. То есть:
– вышел из строя жесткий диск ~ рейд-контроллер сам перестроит рейд-группу без вмешательства системного администратора. Пользователи сервиса ничего не заметят.
– пользователь удалил файл либо запись в инф. системе ~ все, абзац. Аппаратный уровень тут бессилен.
Решения вроде VMware HA или VMware FT относятся целиком к этому уровню (особенно, HA).
Программный уровень
Здесь находятся программные средства, позволяющие продлить жизнь информации. Это всевозможные средства контроля целостности (например, журналы транзакций) и превентивный мониторинг (за исключением мониторинга железа).
Организационный уровень
Ну а здесь идет разграничение физического или программного доступа на несколько уровней. Я бы сюда отнес, например, предоставление доступа к ресурсам на основе групп Active Directory. На этом уровне определяется, кому и что нужно/можно делать.

Если вам нужно защитить ваши системы от программных сбоев, человеческих ошибок и других рисков, ничего лучше резервного копирования еще не придумано. Какая бы у вас супернадежная система не была, хоть XP Storageworks 24000, без бэкапов вы сильно рискуете. Конечно, вероятность сбоя ГОРАЗДО ниже, чем если данные лежат на простом файл-сервере. Но, подозреваю, СТОИМОСТЬ этих данных ГОРАЗДО выше.
Системы резервного копирования можно смело отнести к стыку программного и организационного уровней. Конечно, можно запросто настроить нужные ВАМ (ИТ-специалистам) бэкапы, но вот нужны ли они бизнесу/пользователям? Сможете ли вы восстановить из бэкапов информацию в нужном объеме и качестве за установленные сроки? Есть ли у вас план восстановления на случай системного сбоя? Хранится ли он на бумаге и доступен ли он в чрезвычайной ситуации? У вас есть ответы на эти вопросы?
Службы кластеров – стык аппаратного и программного уровней (как и прочие системы репликации). Распределенный кластер – стык всех трех уровней (как в принципе и любая другая катастрофо-устойчивая система).

Вопросы?

11 thoughts on “Заметка про защиту данных”

  1. Боюсь показаться банальным, но выбору той или иной меры защиты информации (ну или комплекса мер) должна предшествовать некая оценка критичности той или иной информации. И сколько будет стоить эту инфу потерять или прожить без нее, скажем, час-два. А уже после выстраивать стратегию защиты. Имхо бОльшая проблема в том, что как раз ту самую оценку критичности мало кто проводит.

  2. Андрей, самый прикол в том, что в самом распоследнем вшивом NAS есть поддержка рейд. И на форумах, в т.ч. тринити постоянно возникают вопросы о том, как сделать за 3 копейки ДОМАШИЙ NAS с ШЕСТЫМ, сука, рейдом. И это вместо того, чтобы взять два этих диска и писать на них бэкапы.

  3. Они еще про СПАРЕ диски забыли
    :)))
    А все от непонимания.
    Могу привести другой пример. Допустим, у нас есть СУБД. Универсальные рекомендации следующие:
    – разнести файлы баз и логов по разным шпинделям (рейдгруппам);
    – R5/R10 под базы;
    – R1 под логи.
    Однако, если контора МОЖЕТ прожить без работающей СУБД определенное время, и выполняются определенные условия, то под базы я бы предложил использовать НУЛЕВОЙ рейд. 🙂

  4. Вариант разнесения базы и логов работает при очень большом числе дисков, чаще всего имеет смысл объединять диски в один массив.

    В нулевом рейде смысла нет, т.к. выигрыш на малом числе дисков будет невелик относительно зеркала или десятки, а на большом числе дисков – я не могу представить такую задачу, чтобы и много дисков и день простоя 🙂

  5. С теоретической точки зрения, выигрыш при использовании 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. Неожиданно, правда?

  6. Ничего неожиданного 🙂

    Итак, у нас БД с профилем 50:50 и 8 винтов в 10ке

    Идет чтение из базы: доступно 8*200 iops
    Идет запись в базу: и на лог и на бд доступно 4*200 iops поочередно

    Меняем разбивку, делаем две десятки по 4 винта:
    Идет чтение из базы: доступно 4*200 iops
    Идет запись в базу: на лог доступно 2*200 iops по завершению операции – на запись – 2*200 iops

    😉

  7. То есть вы оба считаете, что если у вас будет сотни полторы workers, то их суммарный IOPS будет с диска 200? Потренируйтесь на IOmeter!

  8. 🙂
    Я же сказал, возьмем идеальные диски. Естественно, реальный IOPS гораздо ниже.
    “Оптимисты закладывают по 110 IOPS на FC-диск, пессимисты по 70” (© 2009, HP Accelerated SAN Essentials, Владимир Стригин).
    По поводу записи в базу. В общем случае ты, diz, конечно, прав. Вот только при наличии оперативки наиболее используемые БД лежат в ней и лишь время от времени записывают изменения в базы из лога.
    Соответственно, если 400 IOPS – это максимальные и редко достижимые показатели для нашей СУБД, то в производительность на запись в базу мы не упираемся.

Leave a Reply

Your email address will not be published. Required fields are marked *