Компания Falconstor, один из лидеров рынка систем виртуализации СХД и VTL, объявила о поставках под своей маркой аппаратного решения, в котором используется флагманский продукт NSS (виртуализация СХД) – Network Storage Server HC. Данные системы поставляются в 4х вариантах: 8 и 16 портов iSCSI, 8 x iSCSI + 8 x 4Gbit FC и 4 x 10Gbit iSCSI. Все системы двухконтроллерные и поддерживают зеркалирование, репликацию, мгновенные снимки, а также thin provisioning. Для обеспечения консистентности данных различных приложений при создании мгновенных снимков потребуются спецальные агенты, которые поставляются отдельно. Самая младшая модель раширяется до 224 дисков, а остальные – до 336 (16ти дисковыми модулями). Фактически производителем “железа” выступает компания H3C (Huawei-3Com), которая также и сама продает данные системы (разумеется, уже под своей маркой) - это их линейка IX3040/3080/IX3240/IX3620. С точки зрения “железа” это двухконтроллерные массивы (кластер из двух серверов в одном конструктиве), на которых, помимо ПО для управления дисками (RAID/LUNs), установлен также Falconstor NSS. Я слышал, что поддерживается в т.ч. и подключение сторонних систем для виртуализации, но документальных подтверждений пока не нашел (может быть это и возможно для “чужих” iSCSI систем, а FC там просто некуда подключить).
Насколько это хорошее решение сказать сложно – с одной стороны, все компоненты поставляются "из одних рук и это сильно облегчает жизнь при возможных проблемах. С другой стороны, реализация всего функционала СХД на той же системе, на которой работает сам NSS, может существенно влиять на производительность. Ограниченные возможности по подключению сторонних дисковых систем не добавляют решению “плюсов”. Но вот однако, если вместо NSS использовать VTL – получается вполне привлекательный вариант, так как перестает болеть голова о выборе аппаратной платформы для виртуальной ленточной библиотеке.
Выпуск NSS HC никак не ограничивает поставки чисто программной части NSS –этот продукт по прежнему можно спокойно приобретать и использовать с оборудованием сторонних производителей (как и предполагалось изначально).
Сегодня пару слов о банальном, но, увы, про это часто забывают.
Ни для кого не секрет, что скидки на системный софт (к которому относится и VMware vSphere) обычно сравнительно невелики и “зажаты” в определенные рамки. Да, конечно, под большой проект можно получить хорошее предложение, но большой проект это и большие деньги. А иногда нужно поставить два-три сервера, а чем меньше бюджет решения, тем, как правило, больше желание его еще немного сократить. И именно для таких случаев VMware предлагает пакеты лицензий (так называемые Acceleration Kit), которые обходятся заметно дешевле, чем если бы все лицензии нужно было приобретать отдельно. Про такой вариант приобретения зачастую забывают, а зря. На текущий момент доступны следующие варианты:
Advanced Acceleration Kit – включает 6 процессорных лицензий (на три двухпроцессорных сервера) vSphere Advanced и лицензию на vCenter Foundation (так как vCenter Foundation поддерживает до 3х серверов, возникает ограничение на три двухпроцессорных сервера, и сделать, например, 6 однопроцессорных серверов с такой лицензией не получится).
Enterprise Plus Acceleration Kit for 6 Processors – включает 6 процессорных лицензий vSphere Enterprise Plus и лицензию на полноценный vCenter. Доступны все возможности vSphere, а цена, при этом, заметно ниже.
Enterprise Plus Acceleration Kit for 8 Processors – включает 8 процессорных лицензий vSphere Enterprise Plus и лицензию на полноценный vCenter. Отличный вариант, если ставится две 4х процессорные машины.
Для малого бизнеса действует еще одно очень заманчивое предложение: vSphere Essentials Plus Promotion. Это комплект из лицензий ESX/ESXi для трех двухпроцессорных машин и vCenter for Essentials. Поддерживается до 4х виртуальных процессоров в VM, High Availability, Data Recovery и Update Manager.
В последнее время все чаще возникают вопросы про то, как нужно создавать RAID-массивы и, как следствие, возникают недопонимания и разночтения про такие понятия как LUN и RAID. Разночтения возникают из-за того, что контроллеры разных производителей работают немного по-разному (в плане логической организации) и человек, привыкший работать например с контроллерами Adaptec, имеет сложности, объясняя владельцу контроллера LSI, что именно нужно сделать.
Начну с очевидного: RAID-контроллеры позволяют создать несколько логических дисков “поверх” имеющихся физических дисков. Обратите внимание, что “логические” они именно с точки зрения RAID-контроллера, так как сервер видит их как вполне себе отдельные физические диски. Скажем, если к нашему абстрактному RAID-контроллеру подключено 8 дисков по 1ТБ и сделано два логических диска на 1ТБ и на 7ТБ, то операционная система сервера будет “думать”, что к серверу подключено два диска – на 1ТБ и на 7ТБ (а то, что дисков на самом деле 8, будет “скрыто” за RAID-контроллером).
Часто для обозначения этих самых “логических” дисков применяется термин LUN (его можно читать как Logical UNit, но правильнее – Logical Unit Number, так как исторически этот термин применялся именно для нумерации дисков на SCSI шине).
RAID-контроллеры позволяют по-разному создавать логические диски “поверх” физических. Одни (3Ware, старые контроллеры LSI) позволяют создать RAID-массив из произвольного числа дисков и потом разделить его на несколько частей (именно это чаще всего имеют в виду, когда говорят про “разбиение массива на LUNы”):
Другие контроллеры (новые LSI, Adaptec), напротив, не позволяют делить созданные RAID-массивы на части, но зато позволяют на одних и тех же дисках создать несколько массивов (причем, массивы могут быть созданы разного уровня):
Во втором случае, говорить про “нарезание” LUNов на массиве конечно не совсем корректно (и зачастую сильно затрудняет понимание), но общий смысл остается неизменным – в обеих случаях мы создаем несколько логических дисков на одном и том же наборе дисков физических. Именно так и следует понимать фразу наподобие “выделите под эти данные отдельный LUN”. Речь идет только о том, что для обсуждаемой задачи не требуется весь объем жестких дисков, входящих в RAID-группу, и следует создать средствами контроллера логических диск нужного размера, независимо от того, как это реализовано в используемом контроллере.
HP стал счастливым обладателем компании IBRIX, основным продуктом которой является файловая система Fusion. Таким образом, HP со всех сторон окружена файловыми системами:
PolyServe для одновременного доступа к общему дисковому массиву
SFS (на основе Lustre) для доступа к данным, распределенным между серверами
И вот теперь еще и IBRIX. Конечно интересно, что со всем этим богатством будет делать HP (так как после приобретения PolyServe на слуху она стала появляться гораздо реже чем до). Еще один интересный момент - крупными партнерами IBRIX являются на данный момент Dell и EMC (да и IBM отметился тоже). Если у IBM есть свой аналогичный продукт, то у Dell и EMC на текущий момент - ничего (насколько я знаю).
На одном из блогов HP появилась не так давно отличная заметка про то, как используюется память на новых системах (с нехалемами) и почему Windows 2003 Standard является далеко не лучшим выбором ОС для данных машин.
Если вкратце, то Windows 2003 Standand имеет ряд ограничений: не поддерживает NUMA и не поддерживает более 4ГБ памяти. С другой стороны, память в новых системах организована так, что если установлено, скажем 4x1GB (3 на одном процессоре и 1 на другом), то сначала выделяется память с первого процессора, а потом уже со второго:
Зеленым цветом показана память процессора #1, а синим - процессора #2. Как следствие, помимо того, что у некоторых участнов памяти полоса пропускания меньше, чем у других. И в дополнение - проблема с латентностью, вызванная отсутствием поддержки NUMA.
Можно поставить по 2 модуля памяти на процессор, но проблемы это не решает - пропускная способность будет одинаковая, но ниже максимальной. Еще один вариант - включить в BIOS опцию "node interleaving". Это позволит равномерно распределить память, но не решит проблему с латентностью, так как с большой будем продолжать попадать на память "чужого" процессора:
Можно пойти еще дальше и поставить 6 модулей памяти. Это полностью решит проблему с различной пропускной способностью, но никак не повлияет на латентность (а кроме того, 2ГБ будут просто "потеряны").
Таким образом, как ни крути, а использовать двухпроцессорные системы на нехалемах с Windows Server 2003 Std - не лучший вариант. Решения? Если поставить один процессор, то никаких из упомянутых проблем не будет (так как не будет NUMA). Другой вариант использовать поддерживающие NUMA ОС: Windows Server 2008 или Windows Server 2003 Enterprise.
Меня уже давно занимает вопрос, как нормально можно перевести термин "thin provisioning"? Вроде бы вполне понятно, что именно он означает, но найти нормальный русскоязычный эквивалент проблематично. Выделение дискового пространства по требованию? Звучит сравнительно понятно (хотя и не отражает всего смысла, так как неплохо бы добавить еще "небольшими блоками"), но вместо двух слов получили уже пять, а это уже, пожалуй, перебор. Более короткий вариант я лично придумать не могу, поэтому лучше буду использовать англоязычный вариант.
В HDS пошли другим путем и придумали свой собственный термин "Dynamic Provisioning". С 3го августа Dynamic Provisioning будет доступен для систем серии AMS2000. Какие возможности получает пользователь и как это работает?
Для начала, "как работает". Используя новые возможности, можно объединить несколько RAID-групп в один пул (HDP Pool) и уже из этого пула выделять луны (HDP Volume, Virtual LUN) для серверов. При этом, суммарный объем соозданных Virtual LUN может превышать доступный физически объем. По мере того как очередные блоки данных записываются на LUN, происходит динамическое расширение Virtual LUN. Пространство для Virtual LUN выделяется из HDP Pool блоками (chunk) по 1ГБ (поэтому "thin" это конечно довольно громко сказано). Система осуществляет распределение этих блоков между RAID-группами, входящими в HDP Pool: сначала выделяется chunk размером 1ГБ на первой RAID-групппе (для каждого из Virtual LUN), а когда он будет полностью заполнен, выделяется 1ГБ chunk на второй RAID-группе и т.д. Каждый chunk состоит из 32х страниц по 32МБ, но в данном случае это скорее логическое разделение, так как выделяется все равно пространство минимум в 1ГБ.
Что декларируется? Конечно же, прежде всего, эффективное использование дискового пространства! Разумеется, это большой плюс (особенно когда нет четкого представления, какова динамика роста требований к объему). За счет динамического выделения дискового пространства можно избежать довольно неприятных ситуаций с тем, что нужно создать новый том, а места уже нет, хотя имеющееся дисковое пространство используется неэффективно. Мониторинг используемых ресурсов позволяет заранее спланировать приобретение дополнительных дисков. Кроме того, обещается рост производительности системы за распределения Virtual LUN по многим RAID-группам в рамках HDP Pool (а кто же откажется от такого плюса?).
А есть ли минусы? Ну как же без них! Во-первых, (как я понял) для Virtual LUN можно использовать только ShadowImage, а TrueCopy и Snapshot на текущий момент не работают. Во-вторых, несмотря на то, что заявляется об увеличении производительности за счет распределения Virtual LUN по нескольким RAID-группам, эффект от такого распределения будет очень сильно зависеть от локализации запросов к LUN - так как распределение делается блоками по 1ГБ (если запросы идут к участку данных объемом менее 1ГБ, мы с высокой вероятность будем использовать только одну RAID-группу и уж точно не более двух). Да, мы имеем возможность распределить много LUNов по многим RAID-группам (и это может дать положительный эффект), но вот если, по стечению обстоятельств, запросы будут приходиться на одну RAID-группу, то эффект может быть сильно отрицательный (а вероятность получить именно такую ситуацию при 1ГБ блоке, как минимум, не нулевая). В-третьих, если для систем USP/USP-V есть возможность исключить "пустые" блоки (zero page reclaim), то для AMS2000 такой возможности нет. Помимо перечисленного нужно помнить, что Dymanic Provisioning эффективен не для всех файловых систем (например, для ext2/ext3 эффективность будет сравнительно небольшой, а для UFS использовать HDP вообще нет смысла).
Итог обычен - выбирая решение, нужно не только слушать дифирамбы продавца, но и помнить про технические особенности, а также про то, для чего именно Вам нужен тот или иной продукт.
