В весьма полезном блоге про технологии виртуализации Mirosoft вчера появился очередной пост, на этот раз посвященный копированию файлов на тома CSV. При копировании файла на общий кластерный ресурс (CSV диск) на различных узлах скорость очень сильно отличается. Причина в том, что если узел, на котором происходит копирование, является координатором тома CSV, все операции происходят локально и скорость максимальная. Если же узел координатором не является, то все операции записи перенаправляются на узел-координатор по сети. Конечно же такая проблема наблюдается только при копировании файлов – когда виртуальная машина работает со своим VHD файлом, все операции уже идут исключительно “напрямую”. Соответственно, чтобы минимизировать нагрузку, нужно сначала найти узел-владелец кластерного ресурса (либо через консоль Failover Cluster Manager, либо через powershell), а уже потом именно на этом узле произвести все необходимые операции с файлами. Но есть и другой выход! Я уже писал про него ранее – это кластерная файловая система Sanbolic MelioFS. 
четверг, 29 апреля 2010 г.
Копирование файлов на CSV диск
среда, 28 апреля 2010 г.
Долгострою – бой!
HP анонсировали системы на базе процессоров Itanium 9300 (Tukwila) – это и маленький rx2800, и лезвия BL860c i2, BL870c i2 и BL890c i2 (на картинке), и даже Superdome 2.
вторник, 13 апреля 2010 г.
Cisco сдается (или как раз не сдается)
Идея Cisco завоевать мир SAN, перетянув всех на 10Гбит, таки провалилась. Провалилась она конечно не вчера и даже не позавчера – это было ясно уже давно. Шансы были весьма и весьма призрачны даже в те далекие времена, когда на красивых презентациях только зашла речь о пользе 10Гбит. А сейчас, когда в портфеле Storage Networking у Cisco, все коммутаторы имеют 8ГБит интерфейсы, пропали последние сомнения. Собственно о чем это я? На днях у Cisco был анонсирован 48ми портовый 8Гбит коммутатор MDS 9148.
Теперь можно полностью переходить на 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
Недавно в тестах 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 находится в разумных границах, а это как раз и означает, что масштабирование при “горизонтальном” росте более чем удовлетворительное.
Во всех СХД использовались диски 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-массивом:
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:
Как видно, для максимальной производительности подсистемы памяти на каждый процессор нужно ставить по 8 модулей, равномерно распределяя их по картам памяти (коих приходится по две на каждый CPU). Важно про это помнить на момент формирования “хотелки” на сервер – платы расширения стоят денег, а в большинстве базовых моделей их идет только по 1шт на каждый процессор.
Читать дальше ...среда, 24 марта 2010 г.
В помощь виртуальным и отказоустойчивым :)
Вышла очередная книжка за авторством Mike Laverick, посвященная работе с VMware Site Recovery Manager (SRM). В книге очень подробно и с многочисленными примерами рассказывается о том, как и что можно делать в версии SRM 4.0. Примеры включают в себя не только непосредственно работу с SRM, но и настройку таких систем хранения как EMC Celerra и Clariion, NetApp FAS и HP LeftHand. Самый главный минус для российских читателей – книга на английском языке, впрочем это, к счастью, для многих не самая большая сложность.
Читать дальше ...Новые JBOD от LSI
LSI анонсировал две модели 6Gb/s SAS JBOD (ящики для жестких дисков), предназначенные для подключения непосредственно к SAS контроллерам LSI и 3Ware. Модель 630J имеет 12 отсеков для дисков 3.5’’, а модель 620J – 24 отсека для 2.5’’ дисков. Оба варианта поддерживают 6Gb/s SAS (используется экспандер LSI SAS2x36), имеют стандартную высоту 2U, оснащены двумя блоками питания (система охлаждения находится в блоках питания, поэтому она также дублирована), в базе идет один ESM модуль, но можно установить и второй для обеспечения отказоустойчивости. Поддерживаются диски SAS или SATA (правда пока не очень понятно, будут ли доступны отдельно мультиплексоры для подключения SATA дисков в конфигурации с двумя ESM).
Каждый ESM модуль имеет по два SFF-8088 порта для подключения к хостам и один порт для каскадирования. Последовательное подключение JBOD позволит обеспечить необходимый запас для дальнейшего расширения:
понедельник, 22 марта 2010 г.
Оптимальный stripe-size для RAID-массива
Как посчитать, а что будет если на массиве и SQL, и файловый сервер?
А если SQL работает с дисками блоками по 8КБ, а RAID-контроллер не позволяет задать такой страйп, то наверное все теперь будет работать неоптимально и вообще наверное нужно искать такой контроллер, где stripe в 8КБ можно задать?
На самом деле, все это не совсем так.
То что какое-то конкретное приложение общается с дисками блоками по ххКБ вовсе не означает, что именно такой stipe-size будет оптимальным. Поэтому практически всегда на вопрос “как настроить, чтобы было лучше”, следует простой ответ: “оставьте то значение, которое предлагается по умолчанию”.
Разработчики прошивки тратят много времени на оптимизацию кода прошивки, тратят много сил на обеспечение высокой производительности. Но все эти оптимизации наилучшим образом работают как раз на выбранных в качестве “default” значениях.
До недавнего момента я все это говорил, ссылаясь исключительно на свое понимание вопроса, но на днях представитель Adaptec в своем блоге разместил точно такой же совет:
While there is credibility in doing the maths and trying to match the stripe size to the OS/application requirements, the reality is that the defaults will “normally” walk all over specifying a particular size. Why? Because our engineers spend a lot of time in making the defaults work best. We aim to make an out-of-the-box experience for the majority of users, and put a lot of effort into making the product work without a user having to be a rocket scientist to use it.
Особенно это будет заметно, если размер блоков, которыми приложение общается с дисками, будет больше, чем stripe по умолчанию, а нагрузка создается преимущественно случайным обращением.
Но такая ситуация возникает довольно редко, поэтому если никакие экстраординарные приложения использовать не предполагается, отдайтесь на волю разработчиков и пусть они, зная свой продукт изнутри, выберут для Вас правильные настройки.
P.S. Здесь речь идет о внутренних RAID-контроллерах. В “больших” системах есть свои особенности, связанные с работой кэша, и там оптимизация настроек может дать более заметный эффект.
суббота, 27 февраля 2010 г.
Plug-in для интеграции VMWare и IBM DS 3000/4000/5000
IBM был выпущен плагин для vCenter который позволяет интегрировать управление дисковой системой в общий интерфейс vCenter. Использование плагина позволяет как упростить процесс управления дисковой, так и свести все инструменты в одну точку.
Собственно поддерживаются все модели FC дисковых DS3000/4000/5000. Поддержка SAS и iSCSI заявлена на этот год.
Описание на офф сайте. Там же хорошая PDF дока.
Читать дальше ...среда, 10 февраля 2010 г.
IBM HS22V – лезвие для виртуализации
9го февраля IBM анонсировал новое лезвие HS22V. Название недвусмысленно намекает на то, что прицелом является виртуализация. Действительно, основное отличие от HS22 (которые уже заняли основную нишу в блейдах IBM), состоит в наличии 18 (а не 12ти) слотов под память. А память является, как известно, наиболее востребованным компонентом при внедрении виртуализации серверов – процессорной мощности зачастую бывает много, а памяти почти всегда не хватает.
Вместо двух hot-swap дисков предлагается использовать пару фиксированных 1.8” 50GB SSD дисков (поддерживается RAID-0 и RAID-1). Желающие могут добавить аппаратный RAID с батарейкой (впрочем, не думаю, что для данного лезвия это будет хоть как-то востребовано). Также уже традиционно присутствует разъем для USB накопителя с предустановленной Vmware ESXi (3.5 или 4). Что касается плат расширения, то здесь все осталось без изменений по сравнению с HS22. Базовые модели лезвий используют процессоры X5570 и E5540, можно также заказывать вариант с процессорами E5506 (но массово он поставляться не будет).
Для виртуализации весьма удобно использовать Virtual Fabric Adapter, про который я уже писал. Для тех, кому актуально использование FibreChannel, но уже есть прицел на FCoE и/или 10Гбит также есть хорошее решение - Virtual Fabric Extension Module.
Начало отгрузок HS22V планируются на 16е марта. Кроме того, в интернет просочилось название нового лезвия на процессорах Nehalem EX - HX5. Предполагается поддержка 4х процессоров на собственном чипсете eX5. Напомню, что текущую серию процессоров Xeon MP в лезвиях IBM не встретить – аргументом было повышенное энергопотребление и тепловыделение. А на Youtube давно уже можно найти совместный рассказ IBM и Intel о готовящемся чипсете и апдейте линейки 3850M2/3950M2.
Читать дальше ...
Сообщения
