вторник, 21 июля 2009 г.

HP приобретает IBRIX

HP стал счастливым обладателем компании IBRIX, основным продуктом которой является файловая система Fusion. Таким образом, HP со всех сторон окружена файловыми системами:
  • PolyServe для одновременного доступа к общему дисковому массиву
  • SFS (на основе Lustre) для доступа к данным, распределенным между серверами
И вот теперь еще и IBRIX. Конечно интересно, что со всем этим богатством будет делать HP (так как после приобретения PolyServe на слуху она стала появляться гораздо реже чем до). Еще один интересный момент - крупными партнерами IBRIX являются на данный момент Dell и EMC (да и IBM отметился тоже). Если у IBM есть свой аналогичный продукт, то у Dell и EMC на текущий момент - ничего (насколько я знаю).
Понравился пост? Подпишись через RSSRSS, EmailEmail или twitter!

понедельник, 13 июля 2009 г.

Свободное программное обеспечение

Не могу не дать ссылку на замечательный пост в блоге Анатолия Тенцера, посвященный свободному ПО:

http://itblogs.ru/blogs/cio_anatomy/archive/2009/07/13/51045.aspx

Читать обязательно - особенно сочувствующим :)

Для затравки крохотная цитата: "никогда СПО в долгосрочной перспективе ничего не создаст".

Понравился пост? Подпишись через RSSRSS, EmailEmail или twitter!

четверг, 9 июля 2009 г.

Почему windows 2003 Std для нехалемов это зло?

На одном из блогов 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.

Понравился пост? Подпишись через RSSRSS, EmailEmail или twitter!

среда, 1 июля 2009 г.

HDS Dynamic Provisioning для AMS2000

Меня уже давно занимает вопрос, как нормально можно перевести термин "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 вообще нет смысла).

Итог обычен - выбирая решение, нужно не только слушать дифирамбы продавца, но и помнить про технические особенности, а также про то, для чего именно Вам нужен тот или иной продукт.

Понравился пост? Подпишись через RSSRSS, EmailEmail или twitter!