суббота, 27 января 2007 г.

Нытьё про батарейки.

Часто, когда речь заходит про RAID-контроллеры, следом возникает вопрос про "загадочную" дополнительную опцию - батарейку для защиты кэш-памяти. Иногда ее называют BBU (Battery Backup Unit), иногда просто Battery, HP для своих контроллеров использует сокращение BBWC (Battery Backed Write Cache).
Что это и зачем нужно? Все RAID-контроллеры, которые имеют кэш-память, работают через кэш, т.е. когда приходит запрос на чтение блока данных, контроллер проверяет, есть ли данный блок в кэш-памяти. Если запрашиваемый блок там уже есть, то данные сразу передаются в ответ на запрос. Если искомого блока в кэш-памяти нет, то осуществляется чтения нужного блока с диска, считанные данные помещаются в кэш и затем происходит передача данных в ответ на запрос. Очевидно, что на целостность данных при выполнении операций чтения повлиять ничто не может. Однако, когда контроллер получает блок данных с указанием записать его, возможны варианты. Можно писать "мимо"кэш памяти, т.е. записываемые блоки не будут кэшироваться вообще и подтверждение об успешной записи будет отправлено после того как от жесткого диска(ов) будт получено подтверждение о завершении операции записи. Можно помещать данные в кэш -память и сразу записывать на диски, посылая подтверждение после того, как данные будут записаны на диски. Оба этих режима называют режим сквозной записи (write-through). Как правило, в контроллере реализован один из этих режимов (и никто из производителей не любит давать информацию, как именно реализован механизмwrite-through в их продукции). Совершенно очевидно, что такая реализация позволит обеспечить сохранность и консистентность данных в случае неожиданной перезагрузки или выключения. В то же время, такой подход не дает возможность понизить время записи данных, что особенно критично для случайной нагрузки - производительность "упирается" в производительность и число дисков. Радикально повысить скорость обработки запросов на запись можно, отправляя подтверждение о записи, не после того как данные будут записаны на диски, а сразу после того, как они оказались вкэш-памяти контроллера. Это и есть режим с отложенной записью (write-back). Однако, любая проблема с питанием ставить под угрозу сохранность и консистентность данных. Причем могут потеряться не только последние незаписанные данные, оставшиеся в кэш-памяти контроллера, но нарушенная консистентность может привести к "развалу" всего RAID-массива (несколько дисков будут помечены как сбойные и все данные на RAID-массиве перестанут быть доступными). Для того, чтобы обеспечить сохранность содержимого кэш-памяти конттроллера, и используется специальная батарейка. Она обпеспечивает полную сохранность кэш-памяти от нескольких часов до 3-х дней. При следующем старте системы, контроллер определяет, что в кэше были незаписанные данные и осуществляет запись блоков на диски (все это происходит на этапе инициализации контроллера). Батарейка обычно подключается кRAID-контроллеру, но бывает вариант, когда она совмещена с кэш-памятью (т.н. TBBU - Transport BBU) и может быть переставлена вместе с кэшем на новый контроллер (в случае выхода контроллера из строя).
Частые ошибки:
1) Батарейка служит для того, чтобы на диски успели записаться данные до полного отключения системы.
Это не так - батарейка никак не связана с дисками, она только обеспечивает сохранность содержимого кэш-памяти до следующего включения.
2) Сервер подключен к источнику бесперебойного питания и поэтому никакие больше батарейки не нужны.
Это тоже не верно. ИБП служит для обеспечения автономной работы системы и не больше. Во-первых, данные в кэше могут быть потеряны и после обычного "зависания" системы, спасти от которого никакой ИБП не сможет, а, во-вторых, сам ИБП может выйти из строя и послужить причиной непредвиденной остановки системы.
Вторая ошибка встречается очень часто и, к сожалению, далеко не всегда люди понимают, что это именно ошибка. Иногда, несмотря на все объяснения, понимание приходит только после первого сбоя, приведшего к потере данных. Поэтому ряд производителей поступили очень разумно: IBM ставит BBU на все свои контроллеры с кэшем, а HP не дает возможность включить режим отложенной записи на контроллере без BBWC.
Понравился пост? Подпишись через RSSRSS, EmailEmail или twitter!

четверг, 18 января 2007 г.

Что за ограничение в 2ТБ у дисковых массивов.

В стандарте SCSI изначально использовалась 32-х битная адресация блоков, что дает нам 2^32 =4294967296 блоков на LUN (логический том). Размер каждого блока, в свою очередь, равен 512 байтам, таким образом, размер LUN'а не может превышать (2^32)*512 байт. Если вспомнить, что в одном ГБ содержится 2^30 байт, то становится очевидным, что размер тома не может превышать (2^2)*512 ГБ = 2ТБ. В более новых версиях стандарта SCSI введена поддержка расширенной адресации (LBA64), что дает возможность создавать и использовать тома большего размера. Такой возможностью обладают, например, контроллеры 3Ware, Areca и ряд других. У некоторых контроллеров ограничение 2ТБ действует на LUN, у других - на всю RAID-группу (как, например у LSIMegaRAID). Большинство внешних СХД класса a-brand продолжают иметь указанные ограничения на LUN (в основном из-за необходимости поддержки большого списка сертификаций под различные системы). Обычно такое ограничение дисковых систем в серьезных системах не несет никаких проблем, так как используются менеджеры томов и файловые системы, которые не накладывают подобных ограничений на логический диск в ОС (например, Veritas VxVM). Дисковые системы производителей классом пониже (например Infortrend, Xyratex) уже довольно давно поддерживают тома размером более 2ТБ.
Однако, помимо вышеуказанного аппаратного ограничения на размер LUN'а в большинстве ОС существуют свои ограничения на размер логического диска. В частности, basic диск в Windows также не может быть более 2ТБ. Диск большего размера должен иметь тип GPT, поддержка которых появилась в Windows 2003 server SP1 и выше. Для более ранних версий надо использовать динамические диски и объединять их в один (если реально нужен один логический диск более 2ТБ). В Linux поддержка LBA64 появилась в ядре 2.6.x. Также важна поддержка больших дисков файловой системой, например, ext3 и reiserfs поддерживают разделы более 2ТБ.
Разумеется, в случае подключения внешней дисковой системы, адаптер и его драйвер также должны поддерживать LBA64, чтобы большой раздел был доступен для использования.
Понравился пост? Подпишись через RSSRSS, EmailEmail или twitter!

Начало

Так уж сложилось, что довольно часто приходится отвечать (или получать ответы) на всевозможные технические вопросы, связанные по большей части с серверным оборудованием. И этот блог как раз и предназначен для хранения этих ответов, чтобы лишний раз не писать одно и то же.
Понравился пост? Подпишись через RSSRSS, EmailEmail или twitter!