четверг, 29 апреля 2010 г.

Adaptec + Copy back enable

Как известно, в RAID-контроллерах Adaptec есть замечательная функция “Copy back”. Работает эта штука примерно так: в случае поломки одного из дисков (и при наличии диска Hot-Spare), произойдет обычное перестроение массива на  запасной диск (Spare); как только вместо “трупа” будет установлен новый диск, данные со Spare диска незамедлительно вернутся на свое исконное место (на уже новый диск) и Spare диск будет снова ожидать сбоя. Когда это полезно? Во-первых, если дисков много и массивов создано много, а Copy back отключен – достаточно несколько перестроений и уже без поллитры (или хотя бы без ASM) не разберешься где чьи диски стоят. А вот если Copy back работает, то все массивы останутся на своих местах. Другое применение – если стоят разнородные диски, то можно сделать один Spare диск максимального объема и он сможет защитить все массивы, независимо от того какого размера диски используются. Т.е. если есть RAID5 из 4х дисков по 146ГБ, RAID10 из 6 дисков по 300ГБ и RAID5 из 8 дисков по 450ГБ, то достаточно поставить 1 HotSpare диск на 450ГБ и он защитит все массивы. Конечно он защитит все массивы и без Copy back, но тогда при “вылете” 146ГБ диска и задействовании Spare диска, на нем “потеряется” практически 300ГБ. А вот чтобы вернуть Spare диск обратно, нужно будет “сломать” массив – перевести 450ГБ диск (бывший Spare) в состояние Fail и перестроить массив на новый 146ГБ. А что если диски были 2ТБ? Перестроение займет очень много времени и массив будет находится в критическом состоянии весьма и весьма долго. Случись в это время еще один сбой (для RAID5) и данные можно смело начинать восстанавливать из резервной копии. Если он конечно был.

Для меня всегда было очевидно (или по крайней мере довольно логично), что Copy back должен работать без ущерба отказоустойчивости. Но после того как коллегами были выдвинуты и альтернативные точки зрения, пришлось проверить “вживую”, чтобы не делать голословных утверждений. Опережая события, скажу что все прошло по плану и никаких отклонений не замечено. Теперь подробнее. Делаем RAID5 из 3х дисков, добавляем один Spare диск. После этого включаем опцию Copy back – делается это через ASM, так как по умолчанию она отключена и через BIOS не включается (Step 1 на рисунке). Затем удаляем один из дисков, начинается Rebuild (перестроение массива) на Spare (Step 2). После окончания процедуры (массив перешел в состояние Optimal), устанавливаем новый диск на место почившего. Начинает работать Copy back – идет копирование данных со спаре диска на новый (Step 3), массив в это время находится в состоянии Optimal. Если все проходит нормально, то мы возвращаемся к Step 1, где система также без ошибок. Если в момент работы Copy back случается авария на каком-то другом диске и массив переходит в критическое состояние, то операция Copy back заканчивается с ошибкой (Step 4, который фактически эквивалентен Step 2 с добавившимся сбоем еще одного диска). Массив имеет критический статус, но продолжает быть доступен для работы. В этот момент у нас есть два выхода – либо объявить имеющийся новый диск как Spare (начнется rebuild), либо сразу заменить сломавшийся последним диск – тогда тоже начнется перестроение массива.

image

Так что можно смело включать Copy back (если много дисков и массивов). В других случаях он конечно тоже не сильно помешает, но и толку особенного не будет.

Читать дальше ...

Копирование файлов на CSV диск

В весьма полезном блоге про технологии виртуализации Mirosoft вчера появился очередной пост, на этот раз посвященный копированию файлов на тома CSV. При копировании файла на общий кластерный ресурс (CSV диск) на различных узлах скорость очень сильно отличается. Причина в том, что если узел, на котором происходит копирование, является координатором тома CSV, все операции происходят локально и скорость максимальная. Если же узел координатором не является, то все операции записи перенаправляются на узел-координатор по сети. Конечно же такая проблема наблюдается только при копировании файлов – когда виртуальная машина работает со своим VHD файлом, все операции уже идут исключительно “напрямую”. Соответственно, чтобы минимизировать нагрузку, нужно сначала найти узел-владелец кластерного ресурса (либо через консоль Failover Cluster Manager, либо через powershell), а уже потом именно на этом узле произвести все необходимые операции с файлами. Но есть и другой выход! Я уже писал про него ранее – это кластерная файловая система Sanbolic MelioFS. image При ее использовании все узлы имеют параллельный доступ к общему диску. Производительность уже совершенно не зависит от того, на каком узле мы осуществляем те или иные операции с файлами. “Младший” по функционалу бандл (и, что для многих весьма немаловажно,  самый бюджетный) - Melio Virtualization Product Suite как раз и предназначен специально (и только) для хранения файлов виртуальных машин (как раз там и используются CSV тома, когда нет кластерной файловой системы). Помимо непосредственно файловой системы (которая кстати поддерживает и VSS), в состав пакета входит менеджер томов LaScala и средство для автоматической миграции файлов SILM. С помощью SILM можно переносить неиспользуемые данные на вторичное хранилище (на нем, при этом, вовсе не обязательно должна быть файловая система MelioFS). Общие диски могут быть подключены к серверам как по FibreChannel, так и по iSCSI (фактически не выдвигаются никакие дополнительные требования по сравнению с теми, которые есть при использовании CSV).

Читать дальше ...

среда, 28 апреля 2010 г.

Долгострою – бой!

HP анонсировали системы на базе процессоров Itanium 9300 (Tukwila) – это и маленький rx2800, и лезвия BL860c i2, BL870c i2 и BL890c i2 (на картинке), и даже Superdome 2.

imageМладшие модели построены на базе чипсета “Boxboro” – того самого, который используется и в новых серверах с процессорами Xeon 7500 (Nehalem EX). Самые концептуальные изменения претерпел супердом – из монолита он превратился в матрицу (что-то типа блейда в котором лезвия объединяются в единую SMP систему). Чипсет в этих системах уже используется свой собственный, по традиции названный sx3000. Superdome 2 будет доступен во второй половине этого года, но тесты уже есть. В частности, можно увидеть результаты TPC-H (в категории 1000GB), но вот результат лишь совсем немного лучше прежнего (при тех же 64х ядрах). Хотя, с другой стороны, цена метрики упала примерно на 40%, так что положительные тенденции явно есть!

Читать дальше ...

вторник, 13 апреля 2010 г.

Cisco сдается (или как раз не сдается)

Идея Cisco завоевать мир SAN, перетянув всех на 10Гбит, таки провалилась. Провалилась она конечно не вчера и даже не позавчера – это было ясно уже давно. Шансы были  весьма и весьма призрачны даже в те далекие времена, когда на красивых презентациях только зашла речь о пользе 10Гбит. А сейчас, когда в портфеле Storage Networking у Cisco, все коммутаторы имеют 8ГБит интерфейсы, пропали последние сомнения. Собственно о чем это я? На днях у Cisco был анонсирован 48ми портовый 8Гбит коммутатор MDS 9148.

imageБазовые версии включают 16, 32 или все 48 активированных портов. Приобретать можно как с 8Гбит коротковолновыми трансиверами, так и для экономии - с 4Гбит трансиверами(если нужно подключить устройства, которые 8Гбит не умеют). Как обычно, практически весь функционал уже доступен сразу, без каких либо доплат. Внутри, как и в остальных (9100/9200/9500) братьях “живет” NX-OS. Разумеется, поддерживаются и ставшие привычными всем цисководам VSAN.

Теперь можно полностью переходить на 8Gbit SAN, используя оборудование Cisco (8Гбит лезвия для директоров 9500 были анонсированы уже некоторое время назад).

Читать дальше ...

понедельник, 5 апреля 2010 г.

Windows + Itanium = ?

Очевидцы пишут, что любовь ушла. В том смысле, что 2008R2 станет последней версией для процессоров Intel Itanium. Поддержка сохранится до 2013 года (а расширенная поддержка еще 5 лет), так что все в рамках стандартов Microsoft. Однако новых версий ждать не стоит (равно как не будет новых версий SQL Server и Visual Studio).

Основная озвученная причина – стремительная эволюция систем x86 (не только в плане производительности, но и в плане отказоустойчивости). Кроме того, поставки Windows на Superdome всегда были очень незначительными по сравнению с HP-UX и OpenVMS. Слишком медленное развитие Itanium (как и постоянные, но объявляемые “запланированными” задержки с выпуском процессоров), как мне кажется, играли в данном решении отнюдь не последнюю роль.

Стоит напомнить, что Microsoft не первый - в RedHat не так давно также отказались от дальнейшей поддержки систем на базе Itanium. Второй большой линуксовод (Novell) продолжает поддерживать IA64, но как долго это еще продлится?

Что дальше? HP столько лет всеми силами отстаивала процессоры Itanium, что отказываться от них конечно теперь не будут, но вот останутся ли другие производители или для Intel будет теперь только один покупатель на Itanium?

Читать дальше ...

Infortrend ESVA и бенчмарк SPC-1

image

Недавно в тестах SPC отметился новичок – Infortrend с системой ESVA F60. Сразу надо сказать, что “новичок” в тестах SPC, а вовсе не в производстве дисковых систем. Да и отметился Infortrend сразу с очень даже неплохим результатом - 180,488.53 SPC-1 IOPs. Про особенности ESVA я уже писал, основная “фича”  – возможность масштабироваться не только “вертикально” за счет добавления дисковых полок, но и “горизонтально” за счет объединения до 12ти систем вместе. Собственно, в тестах SPC и было 12 систем, а в каждой по 64 диска (всего 768). С одной стороны, дисков много, но с другой – все, кто имеют лучший результат в этих тестах, имеют и большее число дисков (что вполне понятно, так как SPC-1 гораздо больше зависит от суммарного числа дисков, чем от интеллектуальных возможностей контроллера.

Когда я смотрел на возможности, предоставляемые ESVA, меня довольно сильно тревожило, а действительно ли будет пропорциональный рост производительности? Либо по факту после добавления двух-трех систем все “заглохнет” и дальше будет надеяться только на рост объема системы хранения. Результаты SPC-1 в значительной мере эти подозрения развеяли – ниже я даже специально собрал в таблицу результаты для нескольких систем. Как видим, значение IOPs/диск для ESVA F60 находится в разумных границах, а это как раз и означает, что масштабирование при “горизонтальном” росте более чем удовлетворительное.

image

Во всех СХД использовались диски 146GB/15k. Результат ESVA, как минимум, можно назвать неплохим. А если учитывать начальные вложения, то результат и вовсе замечательный. Если есть подозрения, что требования к СХД будут постоянно увеличиваться, но бюджета на покупку хай-энда нет, то вариант “горизонтального” масштабирования очень привлекателен.

Читать дальше ...

четверг, 1 апреля 2010 г.

Почему не нужно делать QuickInit

Заметка в блоге Adaptec про “full-stripe writes” - что это и почему это плохо? Если в двух словах (и вольном переводе), то контроллер может работать с массивами RAID5 (да и с RAID6 почти также) двумя способами:

  • Записываемые данные могут попадать в “страйп” на одном диске и записывается только этот измененный страйп, да еще и новый блок с контрольной суммой. Т.е. операция записи блока данных в одном страйпе раскладывается на такую последовательность действий: чтение старого страйпа, чтение контрольной суммы, изменение блока данных, изменение контрольной суммы, запись нового блока и новой контрольной суммы. Этим и объясняется почему RAID5 заметно медленнее чем, например, RAID10 на операциях записи.
  • Данные записываются потоком, т.е. сразу пишутся все страйпы на весь набор дисков. В этом случае контроллер “собирает” так называемый full stripe, считает контрольную сумму и все это записывает на диски. Такой способ, очевидно, работает гораздо быстрее, но только в том случае, когда запись идет последовательно.

Но так работает контроллер в том случае, когда есть уверенность, что контрольные суммы верны (т.е. массив полностью проинициализирован и контрольные суммы не содержат заведомо неверных значений). Но, если при создании массива указать опцию “Quick Init”,  никакой полной инициализации не произойдет – будут изменены только метаданные с конфигурацией. Чтобы данные пользователя не пострадали при сбое одного из дисков, в этом случае контроллер обрабатывает операции записи несколько иначе: любая операция записи влечет за собой чтение всех страйпов, изменение нужного страйпа, расчет контрольной суммы, запись “full stripe” обратно на диски. Т.е. всегда пишем “full-stripe”, но недостающие данные сначала считываем с дисков. Таким образом, любая операция записи будет задействовать все диски в массиве. Скорость, при этом, конечно будет заметно ниже, но пока не будет проведена полная верификация такого массива, никакого улучшения ждать не следует.

Отдельно хочу отметить, что использованная здесь (да и во всех документах Adaptec) терминология немного не соответствует принятой в SNIA – Adaptec (да и многие другие,  надо сказать) под словом “страйп” (stripe) подразумевают то, что в SNIA называют “стрип” (strip), т.е. тот блок, которым оперирует контроллер при работе с RAID-массивом:

imageА  вот использованный выше термин “full stripe” как раз соответствует страйпу в терминологии SNIA. Размер страйпа по умолчанию (в текущих версиях контроллеров Adaptec) равен 256КБ, т.е. после Quick Init любая (абсолютно любая) операция записи на массиве RAID5 из 5ти дисков (как на картинке) потребует чтения 256KB*4=1MB с 4х дисков и записи 1.25МБ уже на все 5 дисков. Согласитесь, не очень это должно способствовать производительности. Мораль такова: не нужно использовать Quick Init. Лучше день подождать (выбрать опцию Clear), а потом за пять минут долететь!

Читать дальше ...

Nehalem-EX, IBM и eX5

Про анонс процессоров Nehalem-EX (Xeon 7500), про новые серверы от IBM x3850 X5 (а также и лезвия HX5, и модули расширения памяти MAX5) уже кто только не писал, так что что-то новое тут говорить смысла нет. Но вот читая драфт redpaper под названием “IBM eX5 Porfolio Technical Overview: IBM System x3850 X5 and IBM BladeCenter HX5” я увидел очень интересные данные,  касающиеся оптимального распределения памяти в системе x3850 X5:

image

Как видно, для максимальной производительности подсистемы памяти на каждый процессор нужно ставить по 8 модулей, равномерно распределяя их по картам памяти (коих приходится по две на каждый CPU). Важно про это помнить на момент формирования “хотелки” на сервер – платы расширения стоят денег, а в большинстве базовых моделей их идет только по 1шт на каждый процессор.

Читать дальше ...