Защита данных при хранении

Существует необходимость защиты данных от двух основных напастей:

• повреждения (data corruption). К ним относится прежде всего не желательная модификация данных и, как частный случай, их удаление.
• потери данных (data loss). Более точно следует говорить о потере доступа к данным и разрушении их целостности. 

Приведу примеры. Если кто-то по дури удалил важный файл (т. е. модифицировал файловые дескрипторы) - это data corruption. Если был физически поврежден единственный диск, на котором находились эти данные - это data loss.

Концептуально, пока придумано всего несколько подходов для решения задачи защиты хранения данных:

• RAID - заркалирование данных или использование других методов обеспечения их избыточности (например, parity).

-ЗАЩИЩАЕТ от локальной data loss (выхода из строя дисков), но НЕ ЗАЩИЩАЕТ от data corruption. RPO=0.

Т. к. RAID формируется на уровне физических накопителей, то для доступа к данным при возникновении сбоя не требуется никаких дополнительных действий.

• Clones (клоны или, как вариант, зеркалирование при помощи какого-либо LVM) – полная локальная копия данных.

-В режиме постоянной синхронизации ЗАЩИЩАЕТ от локальной data loss (например выход из строя 2 дисков в RAID5), но НЕ ЗАЩИЩАЕТ от data corruption. RPO=0.
-В режиме регулярной синхронизации ЗАЩИЩАЕТ от локальной data loss, ЗАЩИЩАЕТ от data corruption. RPO= времени с последней синхронизации.

Clone работает на уровне тома и чаще всего используется для защиты данных, уже находящихся на RAID. Восстановление информации требует перевода тома клона данных в режим read/write или восстановления (recovery) на основной том.

• Snapshots (снэпы) – локальная копия только части данных, модифицированной со времени его создания. 

-НЕ ЗАЩИЩАЕТ от локальной data loss на основном томе, ЗАЩИЩАЕТ от data corruption. RPO= времени с создания последнего снэпа.

Snapshot работает на уровне тома и используется для защиты данных, уже находящихся на RAID. Восстановление информации возможно либо с виртуального тома клона, либо с основного основной тома после процесса восстановления (recovery).

• Remote replication (синхронная удаленная репликация) – полная копия данных на другой дисковый массив.

-Синхронная (как вариант, зеркалирование на другой массив при помощи какого-либо LVM) в режиме постоянной синхронизации ЗАЩИЩАЕТ от data loss основного хранилища, но НЕ ЗАЩИЩАЕТ от data corruption. RPO=0.
-Синхронная в режиме регулярной синхронизации ЗАЩИЩАЕТ от data loss основного хранилища, ЗАЩИЩАЕТ от data corruption. RPO= времени с последней синхронизации.
-Асинхронная в режиме постоянной синхронизации ЗАЩИЩАЕТ от data loss основного хранилища, но НЕ ЗАЩИЩАЕТ от data corruption. RPO= времени асинхронности.
-Асинхронная в режиме регулярной синхронизации ЗАЩИЩАЕТ от data loss основного хранилища, ЗАЩИЩАЕТ от data corruption. RPO= времени с последней синхронизации.

Репликация, чаще всего, работает на уровне блоков томов. Хотя, есть продукты, в которых при небольших изменениях асинхронно копируются только саб-блоки, а при больших изменениях файлы целиком. Восстановление информации требует перевода тома удаленной реплики данных в режим read/write или восстановления (recovery) на основной том.

• Backup (резервное копирование) – полная или инкрементальная копия данных на уровне файлов. 

-ЗАЩИЩАЕТ от data loss основного хранилища, ЗАЩИЩАЕТ от data corruption. RPO= времени с последнего резервного копирования.

Есть продукты в которых контроль за изменениями при выполнении резервного копирования происходит на файловом уровне, а данные копируются и дедуплицируются на уровне саб-блоков. Восстановление данных выполняется с резервной копии на уровне отдельных файлов или всей копии как единого целого (Save Set).

• Continuous Data Protection (CDP) – локальная или удаленная репликация с высокой гранулярностью восстановления данных. Применяется как бы “транзакционный подход”. Изменения данных на уровне IO-операций или саб-блоков фиксируется в специальном журнале. Всегда есть возможность восстановления с актуальной или почти актуальной копии данных (в зависимости от того, синхронный или асинхронный режим), но в случае необходимости, можно “откатиться” на нужное количество операций назад.

-near continuous – по сути, реализуется очень частым созданием snapshots. ЗАЩИЩАЕТ от data loss, ЗАЩИЩАЕТ от data corruption. RPO = времени любой точки восстановления.
-continuous – журналируется каждая операция изменения данных. ЗАЩИЩАЕТ от data loss, ЗАЩИЩАЕТ от data corruption. RPO = 0 или до времени любой операции модификации данных

CDP работает на уровне томов. Восстановление информации требует "наката" данных из журнала на том реплики

Семья Буля

Любой "компьютерщик" не понаслышке знаком с булевой алгеброй. Ее изобретатель, Джордж Буль был достаточно интересным человеком, но в этом посте я хотел бы рассказать не о нем, а о его семье.

Буль родился в Англии в семье бедного башмачника. Его отец закончил всего 3 класса школы и в математике был самоучкой. Однако, именно он был тем человеком, который заинтересовал сына науками. Уже к 12 годам Джордж самостоятельно изучил греческий и латинский языки. Чуть позже к ним прибавились французский, немецкий и итальянский. С 17 лет Буль "подсел" на высшую математику, работами в которой в дальнейшем и прославился.

Женой Буля была Мэри Эверест, племянница географа Джорджа Эвереста, извествного своими  геодезическими работами в Индии и в честь которого была названа высочайшая вершина мира Джомолунгма в Гималаях.

Мэри тоже была женщиной не банальной. В отличие от жен других математиков, она понимала научные идеи своего мужа и всячески поощряла его исследования. После смер­ти Буля, Мэри даже написала несколько математических сочинений, пропагандировавших идеи Джорджа.

У Булей было пять дочерей. Старшая, Мэри, вышла замуж за известного математика, изобретателя и писателя-фантаста Чарльза Хинтона.  Внуки Хинтонов тоже прославились. Говард стал энтомологом, а Вильям и Джоан - физиками. Кстати, последняя стала одной из немногих женщин, принимавших участие в работе над американской атомной бомбой.

Вторая дочь Булей, Маргарет, стала матерью знаменитого анг­лийского математика, и даже иностранного члена Академии наук СССР,  Джеффри Тэйлора.

Третья дочь, Алисия, получила почетную ученую степень в Гронингенском университете за исследования многомерных пространств.

Четвертая, Люси, стала первой в Англии женщиной-профессором зав-кафедрой химии.

Но самой знаменитой стала младшая дочь Булей, Этель Лили­ан, после замужества получившая польскую фамилию Войнич. Все мы в школе читали ее революционный “Овод”. Также она является сочинителем еще нескольких романов и му­зыкальных произведений и автором английских переводов стихов Тараса Шевченко.

Все-таки не зря говорят, что талантливые люди талантливы во всем. Даже в создании семьи и производстве потомства...  :)

Фиктивная геометрия диска

Об адресации жестких дисков здесь...

Ниже приведен вывод информации о геометрии диска ноутбука, на котором я пишу этот пост.

C:\Utils>diskpar -i 0

---- Drive 0 Geometry Infomation ----

Cylinders = 7296

TracksPerCylinder = 255

SectorsPerTrack = 63

BytesPerSector = 512

DiskSize = 60011642880 (Bytes) = 57231 (MB)

---- Drive Partition 0 Infomation ----

StatringOffset = 32256

PartitionLength = 60011610624

HiddenSectors = 63

PartitionNumber = 1

PartitionType = 7

End of partition information. Total existing partitions: 1

Обратите внимание, на огромное количество головок (здесь обозначено как TracksPerCylinder). Конечно, таких дисков не существует. Фиктивная геометрия рассчитана исходя из общего количества блоков диска по следующей формуле:

Важно, что при расчетах всегда берутся максимально допустимые значения количества головок и секторов на трек (TracksPerCylinder = 255, SectorsPerTrack = 63). Операционная система получает информацию об общем количестве блоков от самого диска (DiskSize / BytesPerSector = 60011642880 Bytes / 512 Bytes/sec = 117210240 blocks). Далее по формуле можно получить количество цилиндров (117210240 blocks / (255 heads * 63 tracks/cyl) = 7296).

Значения HiddenSectors = 63 и StatringOffset = 32256 (32256 Bytes / 512 Bytes/sec = 63 sec) указывают нам, что раздел 0 начинается с сектора 64. Если бы мы рассматривали файловую систему, расположенную на дисковом массиве, необходимо было бы провести ее выравнивание (file system alignment). Надо не забыть написать, как и почему надо это делать.

Кстати, вы сразу заметили ошибку в выводе diskpar (StatringOffset) :) ?

Конструктив и адресация жестких дисков

Конструкция жестких дисков остается неизменной уже много лет. Несколько стеклянных или алюминиевых круглых пластин (platters или просто “блины”) с нанесенным специальным магнитным слоем (обычно, сплав кобальта) насажены на общий шпиндель (spindle) и вращаются вокруг него как единое целое. Кстати, в неформальном разговоре “шпинделем” часто называют весь жесткий диск. Данные записываются и считываются при помощи самой дорогой и сложной части конструкции – блока головок чтения-записи (read/write heads). Эти головки смонтированы на коромыслах (arm), за точное перемещение которых (stroke) над поверхностью блинов отвечает специальный сервопривод (voice coil actuator).

Поверхность магнитных пластин поделена на большое количество зон в форме очень узких концентрических колец. Они называются треки (tracks). В современных винчестерах количество секторов на трек не постоянно. Оно дискретно увеличивается с удалением треков от центра пластин. Все треки, расположенные на равном расстоянии от центра пластин, называются цилиндром (cylinder). Головки чтения-записи перемещаются над поверхностью пластин как единое целое и поэтому одновременно позиционируются на треки одного цилиндра. Каждый трек, в свою очередь, поделен на некоторое количество регионов, которые именуются секторами (sectors). Секторы является наименьшей единицей адресации данных на жестких дисках. Их нумерация всегда начинается с 1.

В ранних дисковых накопителях применялась адресация данных CHS (Cylinder/Head/Sector). Но способ прямой физической адресации оказался очень неудобен и поэтому во всех современных жестких дисках вместо него используется LBA (Logical Block Addressing). Его суть заключается в том, что все дисковое пространство представляется в виде непрерывной последовательности блоков с простой линейной адресацией. Номер каждого блока однозначно сопоставляется CHS адресу физического сектора жесткого диска. Очевидно, что размер блока LBA всегда равен размеру сектора. В накопителях емкостью более 120GB используется 48bit LBA.

Несмотря на то, что CHS адресация при работе современных операционных систем с дисковыми накопителями не используется, BIOS компьютеров архитектуры x86 необходимо знать физическую геометрию диска. Данная информация также используется в некоторых служебных структурах ОС, например, в таблице разделов (partition table) и загрузочном секторе (boor sector). При этом, необходимо считаться с достаточно жесткими и, несомненно, устаревшими требованиями к постоянному количеству секторов в каждом треке (sectors/track <= 63). Число головок на цилиндр не должно превышать 255.
Для того чтобы удовлетворить таким требованиям, в современных дисках используются различные методы трансляции в фиктивную геометрию CHS.

Об основных характеристиках дисков здесь...

Заметки на полях (Clariion LUNs и MetaLUNs)

• После удаления LUNs стоит делать дефрагментацию RAID group.
• При fastbind процесс background initialization для 4Gbps FC дисков 146GB 15Krpm проходит за ~1,5 часа, а SATA II 4Gbps 500GB 7,2Krpm за ~8,5 часа. 
• При background initialization average write size будет >512KB.
• При создании MetaLUN, все LUNs будут автоматически trespassed на SP, который является default owner для base LUN. Об этом стоит помнить при сбалансированном распределении LUNs по SPs.
• Не стоит менять размер stripe element компонент.
• Используйте в качестве компонентов RAID groups с количеством дисков >=4.
• MetaLUN стоит строить из RAID одинакового размера (например, RAID 10 4+4 или RAID5 4+1). Иначе разобраться с проблемами в производительности будет очень сложно.
• В MetaLUNs нельзя смешивать FC и SATA.
• Striping MetaLUNs имеют лучше производительность, но больше ограничений.
• Члены Striping MetaLUNs не могут быть в различных RAID и должны иметь одинаковый размер в блоках.
• Члены Concatenation MetaLUNs могут быть на одной RAID group. В случае Striping этого делать категорически нельзя.
• Hybrid MetaLUNs более экономичны (популярны с MS Exchange).
• Размер MetaLUN stripe element = Количество дисков данных * Stripe multiplier 
• Stripe multiplier определяется автоматически по количеству дисков данных.

Количество дисков данных	Stripe multiplier
2	8
3	6
4	4
5	3
6	3
7	3
8	2

• Если несколько MetaLUNs на одних и тех же RAID groups, то следует назначать base LUN на различных RAID groups (rotate).
• Процесс MetaLUN expansion сильно понижает производительность всего массива.
• ID членов MetaLUNs автоматически перенумеровываются в высокие номера.

Ограничения на количество LUNs в различных версиях Flare показаны в таблице:

Модель CX4	Ограничения LUNs Flare R29/R28.7
	Max # LUNs	Max # LUNs / Storage Group	Max # Storage Groups
CX4-120	1024/1024	512/256	256/128
CX4-240	2048/1024	512/256	512/256
CX4-480	4096/4096	1024/256	1024/512
CX4-960	8192/4096	1024/512	2048/1024

Системный подход

Мне регулярно приходится читать документы в которых псевдо-наукообразие слога органично сочетается с полной бессмыслицей и попиранием основ Великого-Могучего. Лидером популярности употребления в таких документах, бесспорно, является слово "системный". Считается, что его округлое, чуть щелестящее звучаение успокаивает заказчика и притупляет критическое восприятие действительности, что, в свою очередь, позволяет быстренько ему что-нибудь втюхать.

Надо отдать должное, что обычно "системщину" в документы наливают дозировано. Достаточно, что бы запутать читателя и уверить его в том, что его природное скудоумие все равно не позволит проникнуться глубиной проработки вопроса, но не до полного отрубона мозгов и потери ориентации в пространстве. Однако иногда появляются по настоящему шедевральные эпосы. Как-то мне на проработку проекта попался в руки документ, составленный в одном из крупных интеграторов. В первых же 7 предложениях вариации на слово "системный" встретились 15!!! раз. Например, "Повышение доступности систем реализуется путем построения системы быстрого автоматического развертывания данных систем в резервном вычислительном центре". Звучит, как мантра, а прочтение всего документа вобще вводит в транс.

Силища!!! Уж поверьте мне, Системному архитектору...

RAID write penalty

Отношение количества Back-end и Front-end операций при записи данных называется Write Penalty (WP).

WP зависит от типа нагрузки и уровня RAID. Чем ниже ее значение, тем более эффективно работает этот тип RAID на операциях записи.
Рассмотрим некоторые примеры:

• RAID10 WP=2.

• RAID5 WP=4.
• RAID6 WP=6.

• RAID5 запись полным страйпом (full stripe write, MR3) WP=1+1/#data disks. 

Как получилась эта формула? Количество Frint-end операций при записи полного страйпа равно количеству дисков данных (общее количество дисков-1 parity). Количество же Back-end операций будет равно количеству всех дисков, т. е. #data disks+1. Делим одно на другое и сокращаем. Вуаля...

Замечу, что т. к. WP RAID5 full stripe <2, при последовательной записи RAID5 будет заметно производительней RAID10. Чем больше шпинделей, тем меньше WP.

• RAID5 full stripe write если есть cache backfill WP=1+(1+#back fill disks)/#data disks.

• Clariion snapshot RAID5 Flare R24 WP=7.25, Flare R26 WP=6.50.
• Clariion snapshot фрагментированный RAID5 Flare R24 WP=10.50.
• Clariion snapshot RAID10 Flare R24 WP=8, Flare R26 WP=6. 

О Morley Parity здесь...

Заметки на полях (Clariion RAID)

• Stripe element size = 64KB или 128 блоков. Менять его не стоит.
• Использование RAID6 при random writes маленькими блоками нагружает backend на 50% больше по сравнению с RAID5 . Sequential writes в RAID6 на 10% медленнее, чем в RAID5. Random и sequential reads – одинаково. 
• При random writes маленькими блоками или выключенном write cache RAID5 и RAID6 заметно проигрывают RAID10.
• Чем меньше дисков в RAID5, тем лучше уровень защиты и меньше время RAID reconstruction. 
• Оптимальный размер RAID5 - 4+1. Больше 9+1 делать категорически не стоит.
• Оптимальный размер RAID6 - 8+2 (распределенный между различными шинами 2 DAE 5+5) или 10+2 (распределенный между 3 DAE 5+5).
• RAID3 лучше использовать при sequential reads >2MB и размерах блока >64KB.
• Считается, что RAID10 стоит выбирать при random read >20%. 
• В RAID10 уровень защиты и время RAID reconstruction от количества дисков не зависит.
• Backend IOPS = read% * frontend IOPS + WP * write% * frontend IOPS, Backend MB/s = read MB/s + WP * write MB/s . Например, IO блоками 8KB 70/30 r/w, RAID5, 2000 frontend IOPS, backend IOPS=0,7*2000+0,3*4*2000=1400+2400=3800
• Primary и Secondary sub-mirrors в RAID10 рекомендуется создавать на различных buses (удобнее скриптом из CLI). 
• Создание RAID5 на дисках DAE на различных buses уменьшает время rebuild.
• Процесс RAID group expansion очень сильно понижает производительность всего массива.