ИТ-технологии для профессионалов

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

BladeCenter L2-L3 Ethernet Switch

В шасси можно включить три типа (по большому счету) 1GB свитчей:

  1. BNT 2L/7L, BNT 2L/3L бывшие Nortel, после банкротства называются BNT (Blade Network Technology). Лист-прайс на сегодня 12 000 USD и 2 350 USD соответственно. Как можно догадаться из названия – один свитч умеет управлять до 7-го уровня, второй до 3-го.
  2. Cisco Catalyst 3012 / 3110G / 3110X – стоят 5 625 / 9 713 / 14 680 соответственно.
  3. IBM Connectivity module – стоят около 1700 USD.

Управляемыми являются только представители 1 и 2-ой групп, поэтому, как нетрудно догадаться, в ситуации когда хочется денег сэкономить, но при этом какую-то конфигурацию на свитчах нужно настроить, покупается свитч BNT 2/3L. Он получается самым дешевым управляемым свитчем 2-го, 3-его уровня.

Надо сказать, что в BladeCenter очень любопытная система внутренней сетевой коммутации и свитч  BNT 2/3L в неё включается путем ввода в него определенных ограничений. Про принцип работы этой внутренней сети я постараюсь написать позже.

Особенности же работы Nortel 2/3 связанные с наличием внутренней сети Bladecenter’а и I/O модулей следующие:

  1. Есть 2 внутренних порта MGT1 и MGT2 оба порта имеют скорость – 100 Мбит, в отличие от остальных у которых скорость 1000 Мбит.
  2. Имеется VLAN 4095 в который включены эти 2 порта.
  3. Имеется IP интерфейс который находится в VLAN 4095, причем его адрес задается через AMM Bladecenter’а.
  4. Если посмотреть снаружи MAC адреса всех IO модулей и AMM Bladecenter’а то он у них будет одинаковый и будет совпадать. А если сделать туже самую процедуру изнутри одного из BNT Switch, то он свой MAC будет видеть нормально, а MAC адреса других I/O модулей – видеть одинаковыми.

полезные ссылки про NBT 2/3 (ранее Nortel 2/3L):
http://www.bladenetwork.net/ibm-bladecenter-1.html - собственно сайт BNT (Blade Network Technology) именем которых и называется теперь Nortel 2/3, ссылка на раздел про IBM.
http://www.bladeswitching.com/modules.php?name=Forums&file=viewforum&f=13 – форум по поддержке на BNT.com
http://www.redbooks.ibm.com/redpapers/pdfs/redp3586.pdf – RedBook Nortel Networks L2/3 Ethernet Switch Module for IBMEserver BladeCenter
https://www.ibm.com/developerworks/forums/forum.jspa?forumID=819&start=0 – IBM BladeCenter Forum
http://www.thetollygroupinc.com/TVDetail.aspx?ProductID=296 – сторонняя сертификация функций Nortel 2/3
http://www.redbooks.ibm.com/redbooks/pdfs/sg247523.pdf - RedBook IBM BladeCenter Products and Technology
http://www.redbooks.ibm.com/abstracts/tips0689.html?Open - BNT Layer 2/3 Copper and Fiber Gigabit Ethernet Switch Modules for IBM BladeCenter
http://www.redbooks.ibm.com/abstracts/tips0597.html?Open - Nortel Networks L2/3 GbESM Layer 2 High Availability Enhancements – L2/3 Switch Software Version 1.1

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

Как перешивать DS4000/5000

Периодически случаются ситуации, когда в DS по тем или иным причинам повреждается прошивка, чаще всего причина – некорректно проведенное обновление этой самой прошивки. В такой ситуации система может быть восстановлена, например, обновлением прошивки через rs232 порт. Надо сказать что сервис IBM может предложить сделать эту процедуру пользователю, как крайнюю меру по восстановлению системы. Единственный недостаток в ней то, что руководство которое присылает сервис-мен абсолютно универсальное рассчитанное на все дисковые системы IBM поэтому там много не описанных мест и деталей которые, предполагается, пользователь должен знать сам. Поскольку я не знаю пользователей которые бы легко делали данную процедуру (ну может быть кроме этих самых сервис-менов IBM) я переписал своими словами эту инструкцию, в первую очередь для себя. Вполне вероятно что она может пригодиться еще кому-то. Еще раз хочу отметить, что процедура эта крайняя, а инструкция ниже скорее дополняет то что присылает IBM.

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

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

Как обойтись меньшим количеством IBM DS Storage Partition в Windows

Каждая группа устройств которая получает дисковую емкость от IBM DS требует одну лицензию, так называемую Storage Partition. Их количество в системах по умолчанию не велико, к примеру в 3400 их 4 штуки, в 4700 тоже 4. Это позволяет использовать дисковую для, к примеру, 4-х кластеров поскольку у каждого кластера одинаковый набор LUN’ов и поэтому это 1 Storage Partition. Ситуация ухудшается если мы хотим использовать дисковую для загрузки по SAN серверов, либо просто раздавать LUN’ы серверам индивидуально, тогда требуется по одной дополнительной Storage Partition на каждый такой сервер. Примерная стоимость лицензий на расширение составляет для ds4700 – 4400USD увеличение с 2 до 8 партиций (т.е. за 6 партиции, примерно 700USD за партицию), для ds3400 - 1700USD увеличение с 4 до 8 партиций (т.е. за 4 партиции, примерно 400USD за партицию).

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

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

Результат тестирования контроллера Adaptec 5805, IBM DS3400, IBM DS4700

Вот такая вот странная компания, сравнивать результаты которой позволяет только одинаковое количество дисков в системах (12 штук).

Итак что мы имеем:

1. Adaptec 5805. 8 внутренних портов (подключено 12 дисков с помощью корзины), ЦП - двухъядерный RAID on Chip (ROC), 1.2ГГц, PCI-Express X8, cache: 512МБ DDR2. К нему подключено 12 дисков SAS Hitachi 146GB 15k, в кузове Supermicro SC826. Stripe – 64 kb, все кэши включены. Прошивка версии – 16 501. http://www.adaptec.com/ru-RU/products/Controllers/Hardware/sas/performance/SAS-5805/ – описание на сайте производителя.

2. IBM DS3400 Dual controller. Одна полка, без экспаншенов. В ней 12 дисков SAS146GB 15k. На каждый контроллер приходится 512 MB кэш памяти. Stripe – 128 kb, все кэши системы включены. Прошивка версии – 07.35.41. http://www-03.ibm.com/systems/ru/storage/disk/ds/ds3400/index.html – описание на сайте производителя. В тесте использовался только один контроллер.

3. IBM DS4700-70. Одна полка, без экспаншенов. В ней используются для теста 12 дисков FC 146GB 15k. На каждый контроллер приходится 1024 MB кэш памяти. Stripe – 128 kb, все кэши системы включены. Прошивка версии – 07.15.01.10. http://www-03.ibm.com/systems/ru/storage/disk/ds4000/ds4700/ – описание на сайте производителя. В тесте использовался только один контроллер.

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

Методика тестов СХД с помощью IOmeter

1. Что тестируем?

Дисковые системы или контроллеры с определенным количеством дисков.

2. Зачем тестируем?

Мне кажется, тут скорее был бы уместен вопрос – «зачем тестируем именно так?». Все тесты – чистая синтетика, они дают достаточно условное понимание мощностей систем и их производительности. Естественно они не дают никакой информации и о функциональных возможностях систем и их производительности в больших/меньших конфигурациях.

Также то, что меня подтолкнуло к такой схеме тестирования было отсутствие нормальных сравнительных тестов по единой схеме интересующих меня систем. К примеру, многоуважаемый http://www.storageperformance.org тестирует конфигурации преимущественно Enterprise с количеством шпинделей от 100 и много выше, в реалиях Российского рынка это достаточно редкие конфигурации (которые к тому же крайне редко выбирают по соображениям их производительности).

Результаты тестов, приведенные здесь показывают только поведение систем под строго определенной (причем вырожденной) нагрузкой, их имеет смысл сравнивать только с результатами, которые получены такими же методами.

В качестве дисковых систем/контроллеров я беру то, что есть под рукой и как следствие то, что показало свою актуальность в рыночных условиях. Количество дисков также я беру приближенное к тому, что востребовано.

3. Чем тестируем?

Iometer выбран как чистая синтетика в первую очередь позволяющий точно смоделировать модель запросов. Результаты теста можно сравнивать только с результатами того же теста. Общий посыл рассмотрения результатов – возможность синтетического тестирования системы чтобы понять её сильные / слабые места. Прямым образом результаты нельзя переносить на скорость работы системы под реальными приложениями.

4. Как тестируем?

Полностью переинциализировав диски, создаем райд группу путем «полной постройки» (full rebuild). Создаем лун 10 гб на нем ставим тест, если тестируем несколько контроллеров у СХД – делаем 2 луна каждый назначаем на свой контроллер и ставим тест на них одновременно.

Условия тестирования:
1. Дефолтный размер страйпа для систем, если не указано другое. Паттерн – filesystem (или наподбоие).
2. В дисковых системах включаем (не отключаем) зеркалирование КЭШей контроллеров. Если не указано иное.
3. В дисковых системах оставляем приоритет для тестируемых лунов – нормальный. Дополнительной нагрузки на систему не создаем. 4. Если тестируем 2 контроллера – создаем 1 райд группу, на ней создаем 2 луна, каждый используем через свой контроллер.

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

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

TS LB и как его можно отлаживать

http://blogs.technet.com/askperf/archive/2008/02/25/ws2008-session-broker-load-balancing.aspx

В этой статье - интересна следующая информация: по ключу HKLM\System\CurrentControlsSet\Control\Terminal Server можно задать уровень детализации логов, которые можно прочитать в %systemroot%\system32\tssesdir рядом с базюками самого сервиса.

Реальная потребность повышать степень логирования возникла, когда сервер перестал принимать входящие подключения, причем делал это после принятия данных авторизации. ломал голову 2 дня, думал что связано с работой сети, оказалось что нет неправильная конфигурация всему виной. Помогло выявить проблему – более детальный лог.

http://blogs.technet.com/askperf/archive/2008/02/24/ws2008-terminal-server-session-broker-overview.aspx
2-ая часть статьи из предыдущего абзаца. В этом материале описываются конфигурации с использованием DS и NLB и возможности их комбинирования. Получается, что предпочтительным является вариант использования SBLB (session broker) совместно с NLB так как будет и балансировка на уровне приложения и определение того что узел NLB кластера в дауне тоже сохранится. Для такой конфигурации все узлы должны быть на серверах W2008. Оптимальным будет использование “ping back” с сервера который принял подключение, в этом случае бродкастный трафик NLB минимизируется, поскольку используется только на 1-м этапе подключения клиента к целевому IP адресу за которым стоит NLB ферма. Собственно все последующие подключения будут идти не на IP NLB, а на IP

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

Недостатки Hyper-V

Родился данный текст как результат внедрения продукта в большом объеме и в связи со многими технологиями от MS участвующими в этом же проекте.

итак по порядку

1. отсутствие нормально реализованного teaming для сетевых карт, существующий вариант от broadcom требует донастройки и “из коробки” не работает. Если же у нас узлы hyper-v еще и в кластере – то конфигурация становится невалидной, т.к. использовать на кластерных интерфейсах teaming низя по докам от MS. Т.е. нужно либо больше 2-х интерфейсов либо отказаться от teaming.

2. Необходимо выверять все драйвера для железной платформы. при большом количестве и требования к полному единообразию, это требует напряжения.

3. Огромное количество патчей. Часть из патчей не полностью валидировано поддержкой. Я прихожу к выводу что человек который поддерживает большую ферму hyper-v вынужден очень хорошо уметь контролировать апдейты. Поскольку не все апдейты идут через WSUS это приходится делать вручную. Немаловажно что приходится периодически для апдейтов машинки перегружать.

4. Отсутствие живых миграций. Это конечно не самый важный минус, но учитывая необходимость перегружать сервера после апдейтов периодически это нехороший момент. Да, после релиза 2008R2 лично я его не буду использовать минимум пол года.

5. Отсутствие возможности детализировать приоритеты по сети, дискам. То что есть, сделано на зачаточном уровне и в реальности сложно используемо.

6. Отсутствие поддержки FC устройств внутрь ВМ.

7. Невозможность сделать Failover Cluster между ВМ без iSCSI. Таким образом получается что приходится делать устойчивый iSCSI таргет, т.е. это либо дисковая с 2-мя контроллерами либо еще один кластер, таким образом чисто между ВМ его не сделать.

8. Сложность мониторинга состояния системы и отсылки простых оповещений. Понятно что это достигается средствами SyscOM, но ИМХО сложность продукта сравнима со сложностью самого hyper-v. В итоге получается, что для мониторинга только hyper-v приходится осваивать универсальный инструмент связанный с SQL и т.д.

9. Сложность отладки нештатных ситуаций. Есть ряд ситуаций в которых отладка может быть крайне геморройным занятием. Самое неприятное в том, что ситуация обычна для всех сложных ошибок. т.е. получается что как сложная ошибка – так сразу неприятности.

10. Меньшее количество протестированного оборудования под платформу. Получается что широта поддержки оборудования бьет обратно тем что за такой широтой сложно присматривать.

11. Невозможность добавить в существующую виртуальную сеть более одного физического адаптера с каждого хоста. См выше про teaming.

буду стараться дополнять при возможности, сейчас больше ничего в голову не лезет

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

четверг, 18 июня 2009 г.

Тестирование Intel® X25-E Extreme SATA Solid-State Drive

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

За последние годы производительность процессоров и памяти выросла в десятки раз, а производительность подсистемы ввода-вывода осталась практически неизменной - вырос только объем дисков. Для увеличения производительности нам приходится постоянно увеличивать количество дисков, докупать к массиву новые дисковые полки, использовать более сложные уровни RAID для увеличения отказоустойчивости - и снова терять производительность.

Компания Intel представила два новых SSD накопителя. Это сверхбыстрые твердотельные накопители Intel X25-M и X25-E. Первый рассчитан на системы среднего уровня, а второй, достоинства и недостатки которого я рассматриваю, рассчитан на корпоративный (High-End) сегмент.

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