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

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

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

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

Вопросы?

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

  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 — это максимальные и редко достижимые показатели для нашей СУБД, то в производительность на запись в базу мы не упираемся.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *