RAID-массив и презумпция атомарности

Совсем недавно тема вновь появилась на повестке дня, только уже в об­личьи проблемы отказов при записи на твердотельные диски (ТТД). Многие их произ­водите­ли и поставщики СХД корпоративного класса борются с такими ошибками по­сред­ством новых прошивок, которые обеспечивают последовательное заполнение дискового массива до полного исчерпания места. Пока место есть, ни один из уже записанных блоков данных вообще не будет пере­за­пи­сан, а когда места не останется, блоки будут пере­за­пи­сываться, начиная с самых первых (конечно, из числа тех, которые к этому времени успели освободиться).

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

Технология моментальных снимков, называемая копированием при записи (Copy on Write), только усугубляет положение. Вместо того, чтобы придержать в памяти новые данные для сверки с теми, которые только что были записаны в определенный сектор диска, система занята копированием старых данных в снимок, расположенный в другой части массива. Прикладные программы с большим числом транзакций, которые регулярно перезаписывают свои данные, крайне чувствительны к такого рода ошибкам (это могут быть БД или часто опорожняемые журналы откатов вроде журналов, создаваемых Oracle при подготовке к архивированию). Беда тут в том, что после записи данных и подтверждения успешности этой операции способа исправить ошибку не существует: эта поврежденная информация уже признана достоверной. И, если данные, сохраненные на диске, дей­стви­тельно разнятся с теми, которые были отправлены для записи, дедупликация способна многократно увеличить тяжесть негативных последствий. Если исходный блок был записан в сбойный сектор, и это не было сразу же обнаружено, в процессе дедупликации ссылка на него может заменить сотню других, полноценных блоков, следствием чего станет крупно­масштабная порча данных.

Механизм контроля четности RAID-массива в таких случаях также не всегда полезен: в RAID значение контрольного бита вычисляется уже после записи страйпа. Это значение не всегда можно вычислить в памяти, потому что страйп также не всегда записывается пол­ностью; в случае частичной записи страйпа вычислять биты четности приходится частью по данным, которые уже на диске, а частью — по тем, которые только предстоит записать. Когда данные записывают и считывают, чтобы вычислить значение контрольного бита, это совсем не обязательно означает сверку записанных данных с их первоисточником. Есть несколько способов предотвратить такую ситуацию — в основном они сводятся к вы­чис­лению контрольной суммы для данных, что находятся в памяти. Повторно считывать дан­ные после подтверждения успешности записи ничего не даст, поскольку сравнивать запи­сан­ное на диск больше не с чем; проверку целости следует проводить до очистки кэша записи.

Разные поставщики СХД решают эту задачу по-разному; я же опишу решение, исполь­зуемое в системах NetApp. Файловая структура WAFL осуществляет запись в любой из свободных блоков, но никогда не пишет в блок, где имеются данные. Освобождает блоки фоновая процедура технической профилактики массива (RAID scrub), которая осуществляет поблочную проверку всех дисков СХД на предмет наличия в активной фай­ловой системе или в моментальных снимках ссылок-указателей на каждый из блоков. Если ни одной ссылки не обнаружено, проверяемый блок освобождается от данных и помеча­ется как свободный (точнее будет сказать, что с блока снимается пометка «занят»). Польза от этого двоякая: во-первых, файловая система получает в свое распоряжение ничем не заня­тые блоки, а во-вторых, в качестве бонуса записываемые блоки распределяются по всей поверхности диска, что сводит почти к нулю негативные последствия атомарности. Кроме того, для файловой структуры WAFL профилактика блоков данных означает также общую проверку целости диска, что позволяет прогнозировать отказы также и по результатам контроля технического состояния поверхности, а не просто исходя из работоспособности устройства в целом. После превышения порогового числа сбойных секторов диск при­зна­ется дефектным, вместо него в эксплуатацию вводится резервный диск для оперативной замены, и начинается процедура восстановления массива. Иными словами, в системах NetApp один и тот же блок данных практически невозможно использовать дважды подряд, даже (а точнее — в особенности) в случае высокой частоты повторения транзакций.

Если принять во внимание все, о чем говорилось выше, становится понятным, что чрезмерно заполненная файловая система не сулит вашим данным ничего хорошего сразу по нескольким причинам. Чем ближе к полному исчерпанию дисковое пространство, тем меньше свободных блоков доступно для записи, соответственно, некоторое число блоков данных записывается последовательно. Как следствие, снова выходит на первый план вопрос атомарности, да и в целом растет интенсивность износа дисков — в общем, об архи­вировании и дедупликации надо думать своевременно, файловые системы содер­жать в по­рядке и вообще лучше как следует заботиться о своей подсистеме хранения данных.

Так что не забудьте поинтересоваться у продавца СХД, что предпринято в его системах для защиты данных ото всех этих напастей.