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

вторник, 15 декабря 2009 г.

FCoE удобнее и компактнее

Строить FCoE уже давно можно – все для этого есть: и адаптеры в серверы, и коммутаторы. Наибольший интерес к FCoE можно ожидать при использовании Blade-решений, так как возможности по установке плат расширения зачастую ограничены. Но цена вопроса все еще довольно высока, особенно учитывая то, что для подключения дисковых систем в большинстве случаев требуется использовать не только 10Gbit коммутационные модули в шасси, но и FCoE коммутаторы с FC портами, либо строить отдельную FC инфраструктуру. Для того чтобы упростить ситуацию, IBM анонсировал для шасси BladeCenter H модули Virtual Fabric Extension. Этот модуль подключается через мид-плэйн к коммутатору BNT Virtual Fabric 10 Gb Switch и позволяет использовать FC порты без необходимости установки дополнительных FC HBA плат в сами лезвия:

В лезвия достаточно установить по одному двухпортовому CNA адаптеру Qlogic, а в шасси – различные по количествам вариации из 10Gb коммутаторов BNT и модулей Virtual Fabric Extension. В максимальной конфигурации поддерживается 2+2 модуля (как на рисунке выше); в минимальной - 1+1 (без отказоустойчивости и задействован только один порт на CNA); кроме того, возможен вариант, когда к двум 10Gb коммутаторам подключен только один модуль Virtual Fabric – это обеспечивает максимальное число внешних портов 10Гбит (16шт).

Virtual Fabric Extension Module может работать как в режиме Full Fabric, так и в режиме NPIV, что обеспечивает дополнительную гибкость конфигураций. Дополнительно хочется отметить, что все “высокоскоростные” прелести  доступны только в шасси BladeCenter H (или HT для телекома), поэтому именно это шасси и имеет смысл рассматривать если есть хоть малейшие перспективы для использования 10Gb.

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

понедельник, 14 декабря 2009 г.

IBM SVC Entry Edition

Уже довольно давно IBM предлагает (и надо заметить небезуспешно) свою систему виртуализации СХД – SAN Volume Controller (SVC). Писать про SVC можно много, но сейчас не об этом. Так как внедрение системы виртуализации СХД это своего рода радикальное изменение в инфраструктуре (хотя оно и может быть реализовано практически полностью прозрачно), то решиться на этот шаг не всегда просто. Именно поэтому уже больше года, если не ошибаюсь, была выпущена версия “для неуверенных”, т.е. решение, которое имело ограниченный функционал, но зато гораздо более бюджетное. В отличие от старшего собрата Entry Edition лицензируется по числу жестких дисков которые входят в виртуализуемый объем. Ограничение на момент выпуска составляло не более 60 дисков для кластера SVC. С одной стороны, этого вполне достаточно, чтобы развернуться “в полный рост” с системой начального уровня и организовать репликацию на удаленную площадку, но любое сравнительно серьезное расширение требует перехода на полную версию SVC. Да, этот переход не требует покупки нового железа, но все равно “бьет” по карману.

С выпуском версии SVC 5.1 и нового поколения железной части (на базе серверов x3550M2) возможности Entry Edition существенным образом расширились – поддерживается уже до 250 дисков (а это вполне себе серьезная система получается). Но на этом приятные новости не закончились – теперь совершенно бесплатно доступна лицензия на FlashCopy! А это уже серьезное подспорье, например в развертывании системы резервного копирования, – в частности Exchange 2010 можно будет бэкапить только через VSS (а VSS, в свою очередь, замечательно интегрируется с FlashCopy посредством Tivoli Storage FlashCopy Manager). Единственное о чем следует помнить – не нужно перебарщивать с лицензиями на FlashCopy – они конечно в базе (с годом поддержки) бесплатны, но дополнительная поддержка стоит денег и, если известно, что снимки нужно делать не со всего объема, то на дальнейшей поддержке можно немного сэкономить.

image

Все эти изменения в SVC Entry Edition делают его приобретение весьма заманчивым. Особенно если в хозяйстве уже есть какая-то “старая” система хранения и хочется не только добавить еще одну систему, но и унифицировать управление.

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

вторник, 8 декабря 2009 г.

Вам чай с сахаром или руки с мылом помоете?

Глупый вопрос, не правда ли? Особенно глупо звучит, если Вы вдруг пропустили начало 90х годов прошлого века в России. Зато сейчас заканчивается первое десятилетие уже этого века, а все чаще приходится слышать не менее странную фразу: “зачем бэкап делать, если я уже RAID настроил?”. И звучит это, к сожалению, чаще всего не в момент создания системы, а уже в тот момент, когда данные надо спасать, причем спасать далеко не традиционными способами. И чем дороже был куплен RAID-контроллер, тем больше возмущение – “Я потратил такие деньги на контроллер, я разве похож на Рокфеллера, чтобы еще и резервную копию делать?! Все пропало! Производители сговорились! Нет справедливости на свете! Ведь я купил контроллер как раз для того, чтобы защитить свои данные!” Как Вы понимаете, речь идет главным образом о “домашних” пользователях, но иногда и в малом бизнесе наблюдаются подобные проблемы.

И возмущение это могло бы быть справедливым, если бы только хоть один производитель RAID-контроллеров позиционировал свой продукт как замену резервному копированию. Так для чего же тогда нужен RAID? Может ли он обеспечить защиту данных? Ответ, как это обычно и бывает, не так однозначен: может, но только в некоторых случаях. В каких? Очень просто - RAID (кроме RAID-0) обеспечит доступность данных при выходе из строя одного или более (например, двух в случае RAID-6) дисков. Вот собственно и вся защита, которую теоретически может Вам обеспечить аппаратный или программный RAID. Не больше! Обратите внимание на слово “доступность” – именно это главная задача, т.е. целю является не защита данных вообще, а минимизация возможных простоев. А могут ли данные на RAID-массиве “пропасть”? Конечно могут! И вариантов здесь очень много, вот лишь несколько примеров:

  • Программная ошибка  - самый простой случай и никак не зависит от наличия RAID.
  • Ошибка пользователя – не менее редкий (а скорее более распространенный) вариант.
  • Поломка сразу двух дисков в RAID-5 (либо трех в RAID-6). Скажете, что это маловероятно? Вовсе нет – если используются диски большого объема, то вероятность повторного сбоя во время перестроения (rebuild) массива при выходе одного из дисков заметно возрастает. Кроме того, возможна банальная проблема с блоком питания, который просто “убьет” электронику в нескольких дисках.
  • “Накопившиеся” логические ошибки на массиве. Откуда они берутся? На аппаратных RAID-контроллерах обычно есть кэш, который может значительно увеличить производительность дисковой операций записи. Но если кэш на запись никак не защищен, то неожиданная перезагрузка системы приведет потере данных в кэше контроллера. Если эта перезагрузка произошла, когда данные просто “ждали” в кэше, то будет ошибка на уровне файловой системы. А вот если в момент перезагрузки данные из кэша уже записывались на диски, то часть данных может оказаться записанными, а часть – нет. И теперь уже ошибки есть не только на уровне файловой системы, но и на уровне самого RAID-массива, так как неизвестно какая часть страйпа записана, а какая –нет. Для “отлова” таких ошибок большинство производителей предлагают соответствующие процедуры (consistency check), но кто ими пользуется пока гром не грянул? Защитить себя от этих проблем можно и батарейкой (BBU), конденсаторами с флэш-памятью или отключением кэша на запись. Но первое стоит денег, а второе - производительности.
  • Кэш есть не только на контроллере, но и на самих дисках. И операции записи кэшируются и на самих дисках. Всегда рекомендуется этот кэш выключать, но для SATA дисков и слабеньких контроллеров это радикально снижает производительность дисковой подсистемы. И те, кто не желает получить медленную систему все-таки оставляют этот кэш включенным. Что может случиться? Правильно, как и несколькими строками выше, перезагрузка может повлечь за собой потерю данных в кэше. И даже если контроллер думает, что с массивом все нормально, но на самом диске данные будут записаны совсем не те, которые нужны. И если этот сбой произошел на блоке с четностью, то до тех пор пока с массивом все нормально, данные будут доступны, а как только этот блок будет использован для восстановления (после сбоя совсем другого диска), в восстановленных данных будет “мусор”.
  • Контроллер взаимодействует с дисками, которые могут “отвечать” на команды контроллера с различными задержками (например, когда диск пытается сделать remap сбойного сектора). И контроллер может не дождаться ответа и отправит диск “на покой”. А что будет если это уже второй диск в RAID5? Правильно – данным можно сказать “прощай”. Да, конечно, диски из списков совместимости такими проблемами страдают крайне редко, но вот часто ли домашний пользователь смотрит на эти пресловутые списки? К сожалению  нет, гораздо чаще голосование происходит либо рублем, либо в пользу “любимой” марки.

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

Так может быть, скажете Вы, RAID контроллеры это “зло” и средство для обогащения жадных производителей? Столько ужасов рассказано, может быть RAID дома и не нужен вовсе? Когда же имеет смысл его использовать?

  • Если нужно повысить скорость работы дисковой подсистемы (когда производительности одного диска мало). Если хобби это обработка видео или “игры” с виртуальными машинами, то почему бы и нет?
  • Компьютер – часть домашнего офиса и там хранится коммерчески важная информация. Вам ведь нужно обеспечить защиту данных до того, как будет сделана резервная копия.
  • Жалко времени на переустановку системы в случае выхода из строя диска. Вполне логично, особенно если компьютер это не полигон для испытаний и еженедельная переустановка Windows не входит в воскресное расписание.
  • Хранятся большие объемы данных в оперативном доступе и нет никакого желания восстанавливать их в случае сбоя диска.

О чем же нужно помнить, если решили упростить себе жизнь, используя RAID?

  1. Использование любого RAID, установка BBU, отключение кэшей, регулярные проверки – ничто не гарантирует сохранность данных, если нет проверенной резервной копии.
  2. Копии важных данных должны храниться на разных носителях и очень желательно, чтобы один из этих носителей не был бы доступен для записи.

А ниже несколько рекомендаций на случай, если все-таки хочется наплевать на все то, что было сказано выше, и сделать по-своему:

  1. Создавая RAID-массив, записывайте все настройки (порядок дисков, размер страйпа и т.п.). Записывайте даже если Вы просто приняли все предлагаемые значения. Фактическое значение этого самого “default” для разных версий прошивки (firmware) аппаратного контроллера может отличаться. Разумеется не нужно хранить эти данные в текстовом файле на самом массиве – не пожалейте листа бумаги.
  2. Поддерживайте актуальную версию прошивок и драйверов. Хотя и не нужно бросаться грудью на амбразуры и устанавливать новую прошивку в день ее выхода – если у Вас сейчас нет проблем, подождите с недельку-другую, может быть именно с ней возникнут проблемы и она будет вскоре заменена.
  3. Используйте все доступные средства мониторинга. Если о случившемся сбое Вы узнали не из сообщения об ошибке в почте, а из того что система уже не загружается, зачастую уже поздно бывает что-то спасать.
  4. Делайте регулярную проверку целостности данных.
  5. Сделайте копию хотя бы самых-самых важных данных, например на DVD диски.
  6. Если планируете что-то изменить в конфигурации массива (добавить диски, изменить уровень RAID и т.п.), перечитайте еще раз пункт №5 (а лучше все это сообщение). Если изменение прошло успешно, вспомните про пункт №1 и измените соответствующие записи.
  7. Для аппаратных контроллеров диски выбирайте не по цене или общему впечатлению о бренде, а из списков совместимости для данного контроллера.
  8. Если что-то сломалось, прежде всего скопируйте самые важные данные, а уже потом занимайтесь самолечением.
  9. Если сломалось все так, что данные уже недоступны, не делайте резких движений и обратитесь к профессионалам. Найти таковых не представляет особенных проблем – даже если Вы находитесь вдали от двух столиц, общение можно свести к пересылке по почте и телефонному общению. Поверьте, почтовые затраты померкнут на фоне стоимости работ по восстановлению. Если есть возможность, сделайте посекторную копию всех дисков и экспериментируйте уже “на кошках”.

Все это конечно не оградит Вас от потери данных, но поможет заметно снизить риск этих потерь и вполне возможно сделает чуть ниже стоимость работ по восстановлению (если все-таки час “Х” настанет). Еще раз: будьте готовы к тому, что для восстановления данных нужно будет обратиться в специализированные организации. И не удивляйтесь когда стоимость работ окажется в несколько раз выше цены дисков и контроллера вместе взятых. Если же такие траты Вам не по плечу, то задумайтесь еще раз о резервном копировании тех данных, которые не хотите терять. И мойте руки с мылом, а в чай кладите сахар.







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

вторник, 24 ноября 2009 г.

Сколько должно быть разъемов на контроллере?

Наболело! Чуть ли не каждый день вижу вопросы такого плана: “В сервер можно поставить 16 (24) жестких диска, а SAS RAID контроллер у меня только 8-ми (или того хуже 4х) портовый! Что мне делать? Это наверное ошибка в конфигурации?!”. Ну что на это можно сказать? Может быть это конечно и ошибка, но скорее всего нет. Как же так? А все очень просто: SAS это протокол последовательной передачи данных и поддерживающий коммутацию. Если Вам нужно к серверу подключить 7 рабочих станций, Вы же не ставите в сервер 7 сетевых карт, а используете коммутатор на 8 портов, который позволяет всем машинам получить доступ к серверу. Точно также и в данной ситуации: либо в самом корпусе (прямо на бэкплейне), либо в виде отдельной карты присутствует аналог этого самого коммутатора. Только в данном случае он называется SAS-экспандером и позволяет подключить к RAID контроллеру гораздо больше дисков, чем есть SAS линий на самом контроллере. Наиболее распространены экспандеры на базе чипов LSI: LSISASx28, LSISASx36 или LSISAS2x36 (для 6Gbps SAS). В частности, на бэкплейнах в корпусах Supermicro используются экспандеры именно LSI. Отдельные карты с экспандерами также существуют, например в России проще всего найти их среди продукции компании Chenbro.

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

Вот вроде бы и разобрались – для подключения 24х дисков вовсе не нужно 24 порта на контроллере, достаточно и 4х (так как обычно именно 4 SAS линии используется для соединения контроллера с экспандером). А используя контроллер с 4мя внутренними портами и 4мя внешними можно не только задействовать (при использовании экспандера все диски в сервере, но и обеспечить возможность дальнейшего увеличения дисковой подсистемы за счет добавления внешней дисковой полки (JBOD).

Но сразу возникает несколько новых вопросов: “А нужно ли использовать экспандер? Может быть он так замедляет работу, что от него надо отказаться? У меня целых 24 (а то и еще больше) диска подключено только по 4м линиям SAS – наверное это будет очень медленно?”.

Попробуем найти ответы. Начнем с конца: 4 SAS линии по 3Gbps дают в сумме 12Gbps, а это целых 1.5 Гига-байта в секунду. Можно ли реально достичь такой пропускной способности? В принципе можно, но (а) нужно помнить, что наверное с этим потоком нужно еще что-то делать, а не просто читать или писать и (б) дисков для этого потребуется (даже при благоприятном стечении обстоятельств) заметно больше десятка. А если учесть, что при типичной работе сервера запросы к дисковой подсистеме идут в значительной степени случайные, то полосы пропускания в 12Gbps оказывается вполне достаточно – можете проверить сами на любом своем сервере, запустив perfmon (под Windows) и посмотрев на трансфер с дисков во время работы. А что до возникновения дополнительных задержек при использовании экспандеров, то они конечно есть, но “поймать” (измерить) их Вам не удастся – настолько они малы по сравнению с задержками при обращении к жесткому диску. Есть и еще один аргумент, чтобы не бояться экспандеров – в RAID-контроллерах, где количество портов больше 8, зачастую это объясняется именно наличием интегрированного на плате экспандера – например Adaptec 51245, 51645, 52445. Так что по сути, делая выбор в пользу многопортового контроллера, Вы просто приобретаете SAS экспандер на одной плате с контроллером.

Итак, использование SAS экспандеров не только не противопоказано, а вполне оправдано в подавляющем большинстве случаев!

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

среда, 18 ноября 2009 г.

HP Virtual Connect для чайников

HP выпустили книжку “HP Virtual Connect for Dummies” – на 76 страница кратко и понятно объясняются основные моменты построения коммутации для Blade-серверов HP. Первые 2500 зарегистрировавшихся могут скачать книжку бесплатно.

image

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

понедельник, 16 ноября 2009 г.

Бесплатный сыр (софт) без мышеловки.

Не так давно VMware объявила о доступности VMware vCenter CapacityIQ – плагина для vCenter, который дает возможность анализировать нагрузку на серверы, а также делать прогноз в стиле “что если”. Плагин является платным, но (как и для других продуктов VMware) можно скачать 60ти дневный триал. Схожие продукты были и у других компаний, например, VKernel поставляла (также платный) Modeler. Но вот на днях было объявлено, что теперь (по крайней мере до 31 декабря 2009г) данный продукт доступен совершенно бесплатно на неограниченное число хостов. Возможностей у Capacity Modeler достаточно, чтобы удовлетворить самые разные требования. Так что если нужно планировать увеличение нагрузки за счет добавления новых виртуальных машин, а бюджета на CapacityIQ уже нет, то решение от VKernel будет очень кстати. Конечно же, данная акция рассчитана прежде всего на привлечение клиентов к более “вкусным” (но уже не бесплатным) продуктам VKernel, но никто не мешает Вам ограничится только бесплатной (и от этого ничуть не менее полезной) частью.

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

понедельник, 9 ноября 2009 г.

Объединяй и властвуй!

Очень часто, говоря про блейд-серверы или про виртуализацию, я сталкиваюсь с тем что собеседники ошибочно воспринимают эти технологии как средство объединения ресурсов нескольких физических серверов в один большой. Тогда как на самом деле, блейд-серверы это всего лишь удобным образом упакованные в один корпус совершенно независимые машины. Виртуализация же серверов, в свою очередь, предназначена для консолидации нескольких задач (виртуальных машин) на одном физическом сервере:

image

А все дополнительные возможности (с красивыми названиями Live Migration, VMotion, DRS, HA и т.п.) служат для управления виртуальными машинами и их перемещением между серверами, но никак не для того, чтобы объединить ресурсы нескольких серверов для распределения между ними одной “тяжелой” задачи.

Хорошо, скажете Вы, а что делать, если стоит задача именно увеличить процессорную мощность системы по сравнению с имеющимся сервером? В большинстве случаев решением является приобретение сервера с большим числом процессоров. Но если задача реализована на x86 архитектуре и работала на двухпроцессорном сервере, то приобрести 4х процессорную машину можно без проблем. 8-ми процессорные системы тоже есть, но выбор гораздо меньше, а цена заметно выше. Ну а дальше? 32 процессора в одном сервере x86 уже фактически неразрешимая проблема – нужно переходить на другую архитектуру, что тоже не всегда возможно (да и требует более серьезных финансовых вложений). Для целого ряда задач решение есть – построение кластеров, где задача “распараллеливается” между серверами. Наиболее на слуху наверное Oracle Real Application Clusters (RAC) – несколько серверов объединяются для параллельной обработки запросов к СУБД, тем самым, увеличивается производительность системы. Другой, не менее часто встречающийся пример, – HPC (High-performance Computing), где вычислительная задача также разделяется на несколько подзадач, которые выполняются параллельно на нескольких вычислительных узлах. Оба эти примера объединяет одно – для работы требуется специальным образом оптимизированное приложение. В тех же случаях, когда такая оптимизация не была сделана, приложение работать либо вообще не будет (наиболее вероятный вариант), либо эффект от его запуска на кластере будет в лучшем случае нулевым. Кроме того, для успешной работы приложения необходимо приложить немало усилий к настройке самого кластера (например, в ряде случаев требуется наличие кластерной файловой системы, обеспечивающей параллельный доступ к данным с нескольких узлов).

Однако уже давно существуют способы объединить серверы через интерфейсы с низкой латентностью и высокой пропускной способностью (например Infiniband), а это, в свою очередь, открывает двери для протокола RMDA (Remote Direct Memory Access). RDMA позволяет приложению, исполняющемуся на одном сервере, получать доступ к оперативной памяти другого сервера, как если бы эта память была его собственная. Казалось бы, стоит сделать небольшой шаг и можно будет именно объединить ресурсы нескольких машин вместе, без необходимости в модернизации приложений и прочих сложностей, но до недавнего времени таких решений не было.

Но на днях мне попалась заметка со ссылкой сразу на двух производителей, которые “взяли быка за рога”: Scale MP и 3leaf Systems. Оба решения позволяют объединить несколько обычных серверов в один большой виртуальный SMP сервер, выполнение на котором приложений не требует их модификации для работы на кластере. Фактическая реализация очень похожа – для создания “объединительной” среды используется высокоскоростной интерфейс. 3leaf Systems используют свой собственный ASIC, который на текущий момент устанавливается в кастомизированные платы Supermicro для процессоров AMD, но в ближайшее время планируется решение и на процессорах Intel Xeon с поддержкой QPI. Dynamic Data Center Software позволяет выделять приложению ресурсы с гранулярностью на уровне отдельных узлов, либо на уровне процессорного ядра, а в скором времени обещают и динамическое выделение ресурсов без перезагрузки виртуальной машины. Уже сейчас можно использовать вместе до 16ти серверов (до 192 ядер) и суммарно до 1ТБ памяти.

Решение же от Scale MP может работать на самых разных системах, а для связи узлов друг с другом используется Infiniband. Серверы в рамках даже одного кластера могут отличаться друг от друга, наверное в т.ч. и из-за этого технология называется vSMP (v – versatile, универсальный).

imageОсновной продукт – vSMP Foundation for SMP является наиболее "продвинутым” вариантам и позволяет объединить до 255 ядер и 4ТБ памяти в один SMP сервер, поддерживается деление общего процессорного пула между виртуальными машинами (одна VM должна включать минимум два узла), для небольших конфигураций можно обойтись и без Infiniband коммутатора – узлы можно соединять друг с другом напрямую. Более бюджетный вариант vSMP Foundation for Cluster отличается от “старшего” брата ограничением памяти в 512ГБ и использованием процессоров не старше 2.4ГГц. vSMP Foundation for Cloud позволяет динамически вводить машины в общий пул –загрузка производится по сети (а не с флэшки, как в остальных вариантах). Очень интересной возможностью является использование различных конфигураций в рамках одного кластера: для приложений, крайне требовательных к объему памяти, но не столь требовательных к числу процессорных ядер, можно строить систему, в которой часть узлов с быстрыми процессорами предназначена непосредственно для исполнения приложения, а другая часть – со сравнительно медленными процессорами, но большим объемом памяти, используется только для увеличения общей оперативной памяти, выделяемой приложению (процессоры этих узлов не будут использоваться для работы пользовательского ПО):

image Конечно же, такое “объединение” ресурсов не является заменой failover кластеру – любая аппаратная проблема внутри такой системы приведет к полной остановке приложения и потребуется перезапуск системы. Возможность изоляции сбойного узла предотвращает длительный простой, но если требуется высокая доступность приложения, то помимо объединения ресурсов в “большой” SMP сервер, необходимо предусмотреть и такие способы резервирования как кластер высокой доступности.

С учетом того, что цены на Infiniband снижаются все сильнее и построение инфраструктуры уже практически эквивалентно стоимости FC SAN, описанные решения по построению больших SMP систем имеют довольно много шансов занять вполне заметную нишу. Причем, от чисто вычислительных задач интерес постепенно будет смещаться в сторону бизнес-приложений (СУБД и т.п.).

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

вторник, 3 ноября 2009 г.

Еще один RAID контроллер для IBM System x

Вчера, в день анонсов, IBM объявил о доступности довольно простенького контроллера ServeRAID M1015. Это уже третья модель у IBM для 6Gbps SAS 2.0. Из возможностей – RAID1/0/10 и поддержка до 32х дисков SAS/SATA. После установки M1000 Advanced Feature Key появляются RAID5 и 50 и encryption. Контроллер построен на базе чипа LSI SAS2008 и, как я понимаю, не имеет прямого аналога в линейке LSI MegaRAID. Ни кэш-памяти, ни возможности поставить батарейку нет, так что применение довольно ограниченное, но как достойная замена BR10i вполне подойдет.

image

Заодно был выпущен и M5000 Advanced Feature Key для контроллеров M5014 и M5015 – после его установки появляется RAID 6 и 60, а также возможность использовать encryption.

Обновился также документ ServerRAID Adapter Quick Reference, в котором содержится информация по возможностям и совместимости контроллеров для серверов IBM System x.

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

Еще немножко про Veeam

Я уже некоторое время назад писал про анонс Veeam Backup & Replication 4.0, теперь его можно совершенно спокойно скачать и попробовать (а те, кто уже купил и находится на поддержке – обновиться).

Кроме того, наткнулся на пару роликов про продукцию Veeam. Рекомендую посмотреть тем, кому лень читать – хотя и с прицелом в маркетинг, но довольно внятно рассказывается про возможности.

 

А тем, кто решил приобрести VMware vSphere Essentials (недорогой вариант на 3 двухпроцессорные машины), рекомендую обратить внимание на специальный бандл от Veeam – Veeam Essentials, в состав которого входят три продукта Backup & Replication, Reporter и Monitor и все это сразу на те же 6 сокетов. В результате, получается удобная в обращении инфраструктура и закрыты не только вопросы управления, но и резервного копирования.

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

пятница, 23 октября 2009 г.

Аварийное восстановление BIOS на материнских платах Supermicro X8xxx

Если BIOS который был поврежден был выпущен позже февраля 2009 года, то можно сделать такой финт:

  1. скачать последнюю версию BIOS подходящую для матплаты с веб сайта и переименовать его в SUPER.ROM, положить этот файл вместе с afudos.exe на флэшку.
  2. Вставить флэшку в USB порт и включить систему кнопкой включения системы 8).
  3. Когда система включится, нажать Ctrl + Home.
  4. Система должна начать прошиваться сама собой
  5. Когда система обновится, произойдет автоматическая перезагрузка.
Читать дальше ...

VMware ESX и новые платформы Supermicro

На всех новых платформах Supermicro под CPU 55xx стоят сетевые карты Intel 82576 в ESX 3.5 U4 или ESX 3.5 U3 нет под них драйверов и для их работы необходимо воспользоваться специальным диском с драйверами, иначе ОС просто не установить по причине отсутствия сетевой карты.

http://www.vmware.com/support/vi3/doc/drivercd/esx35-igb-350.1.3.8.6.3.html вот на этой страничке из KB WMware можно скачать эти самые диски для версии ESX 3.5 U3 и U4. Если говорить про новую установку, то её следует начинать именно с этих дисков и в ходе установки программа запросит диск собственно с ESX когда он понадобится.

С ESX 4 наблюдается схожая ситуация только там немного другой процесс установки ссылка на KB VMWare http://www.vmware.com/support/vsphere4/doc/drivercd/esx40-net-igb_400.1.3.19.12-1.0.4.html

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

пятница, 2 октября 2009 г.

Infortrend ESVA – виртуализация в дисковой системе.

Это очередное сообщение из разряда “старых новостей”, но по ряду причин добрался я до этих систем только сейчас. Пост получился длинным, поэтому прошу прощения за “много букв”.

Многие знают компанию Infortrend как производителя бюджетных дисковых систем (из разряда “один контроллер, набить любыми дисками и вперед”), а некоторые даже помнят SCSI RAID-контроллеры, которые ставились в пяти-дюймовый отсек.

imageОснованная в 1993 году компания изначально занималась только RAID-контроллерами, а потом пришла и к выпуску дисковым системам. Звезд с неба не хватают, но железки делают довольно стабильные и производительные (что немаловажно). Причем контроллеры их ставились не только в “свои” системы, но и поставлялись другим производителям, например, они использовались в системах DotHill SANnet, которые, в свою очередь, продавал под своим именем SUN.

Но похоже что сейчас соревноваться с множеством “нонейма” становится все сложнее и Infortrend решил выйти на новый уровень: в июне этого года общественности были представлены системы ESVA (Enterprise Storage Virtualized Architecture), призванные, как даже из названия понятно, занять место в новом (для Infortrend) сегменте рынка. Конечно и раньше двухконтроллерные системы некоторыми заказчиками ставились для важных приложений, но открытыми оставались много вопросов. Один из них - "время жизни” продукта: как долго после анонса о снятии с продаж будут доступны запчасти. Не менее важным является и вопрос замены вышедших из строя компонентов.

image

Какие же особенности у новых систем? Во-первых, все массивы архитектуры ESVA поставляются только с дисками, поэтому заказчику уже не нужно выбирать диски самому, потенциально рискуя “нарваться” на несовместимость. Хостовые интерфейсы либо FC (8Gbit), либо iSCSI (в настоящее время с портами 1Gbit, но совсем в недалеком будущем будут и модели с 10Gbit), “вертикальное” расширение (полками) достигается при помощи SAS интерфейса. Все компоненты дублированы (контроллеры, блоки питания, вентиляторы). Кэш контроллеров защищен батарейкой (BBU), но для систем с 3.5” дисками батарея не поддерживает кэш все время а служит для того, чтобы в случае проблем с питанием, произошел “сброс” содержимого кэша в энергонезависимую память (флэш-накопитель). На всю серию ESVA обещана пятилетняя доступность запчастей (уже после снятия конкретной модели с продаж). Вы скажете, что это конечно всё важные (очень важные) мелочи, но системы, нацеленные в “энтерпрайз” класс должны иметь и соответствующий функционал! А с функционалом у привычных Eonstor-ов всегда было негусто – вот только совсем недавно появились снапшоты (а у кого их сейчас-то нет?), да вот собственно и все возможности. И можно было бы ожидать каких-то косметических улучшений, но нет -  архитектура ESVA действительно значительно превосходит все то, чем мог нас порадовать Infortrend раньше. Помимо буквально необходимой для систем такого класса синхронной и асинхронной репликации и клонов (а про снапшоты наверное и упоминать не нужно), появилась такая технология как “thin provisioning”. Я уже очень давно думаю, но не представляю как можно коротко и внятно перевести на русский язык этот термин. Смысл технологии в том, что хосту предоставляется LUN размером, скажем 20ТБ, но фактически на дисковой системе этот LUN занимает столько места, сколько на нем сейчас есть данных (фактически у нас даже может вовсе и не быть всех этих 20ТБ на системе хранения).

imageНо и это не главное – основная особенность новой линейки – “горизонтальное” масштабирование (как объема, так и производительности). Если в какой-то момент нам становится недостаточно имеющегося объема, мы конечно как обычно можем добавить еще одну полку с дисками, но когда нам недостаточно производительности, то, в случае использования традиционных систем, приходится переходить уже на новую СХД, приспосабливая имеющуюся под другие нужды. При этом, миграция данных с одной системы на другую – процесс болезненный и зачастую дорогостоящий. Более того, приходится не только останавливать приложения на время миграции, но и есть ненулевой шанс потерять данные и потом восстанавливать их из резервной копии, что только увеличивает общие затраты. В случае с ESVA такой головной боли нет – достаточно добавить еще одну систему и она включится в общий “пул” – данные автоматически будут перераспределены между системами и, в зависимости от числа узлов в таком кластере, общая производительность возрастает практически линейно. В один пул можно объединить до 12ти массивов ESVA, что дает суммарно 1344 диска.

imageИзлишне наверное говорить, что и объемы дисковых систем также объединяются (общий размер Virtual Pool может достигать 2PB) и уже нет той проблемы, когда есть две системы хранения, на одной системе осталось свободных 3ТБ, на другой - 2ТБ, а нам нужно для одного из хостов создать диск размером 4ТБ. В случае с ESVA после добавления второй системы, общий свободный доступный объем составит 5ТБ и можно создать том на 4ТБ (даже не используя thin provisioning).

imageЕсли вдруг нам потребуется удалить систему из пула, то такое действие также возможно – можно дать соответствующую команду и данные будут перераспределены так, чтобы можно было произвести отключение одной из систем (если конечно на оставшихся достаточно свободного места).

По сути своей предлагаемое Infortrend’ом решение является системой виртуализации СХД, которая находится в самой СХД, а не вне ее, как это реализовано например в IBM SVC, Falconstor NSS или HP SVSP.  Конечно нельзя сказать, что это что-то совсем-совсем новое – довольно давно на рынке присутствуют системы EqualLogic (поставляются сейчас от имени Dell), которые тоже умеют масштабироваться горизонтально, однако они не могут быть расширены добавлением JBODов и в качестве хостового интерфейса имеют только iSCSI. Схожую реализацию можно наблюдать и в системах 3PAR, правда там уже нельзя объединить вместе несколько отдельных систем с целью повышения производительности или увеличения объема пула данных.

Несложно догадаться, что цена на массивы серии ESVA конечно же не та, что на Eonstor’ы, но тот функционал, который предоставляется, того стоит. Продажей этих систем занимаемся в том числе и мы, так что – милости просим!

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

четверг, 1 октября 2009 г.

Достоинства Microsoft Hyper-V

Некоторое время назад я писал про недостатки MS Hper-v с которыми я столкнулся в практическом внедрении. Прочтя тот текст могло сложиться впечатление, что продукт вообще не нужный и ни к чему не подходит, но это не так.

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

1. Это виртуализация от Microsoft и она работает! Как это не смешно звучит, но это очень сильный аргумент и из него вытекают многие другие  аргументы ниже.

2. Ядро системы базируется на Windows Server. В результате администраторам, которые исторически работают только с системами Microsoft, нет необходимости изучать Unix. Все же полноценное администрирование VMware без знания RedHat Linux невозможно. Самый просто пример – установка драйвера устройства отсутствующего в системе.

3. Продукт имеет встроенный функционал по обеспечению отказоустойчивости реализованный с помощью Failover Cluster. Что любопытно, имеют право на жизнь конфигурации в которых узлы кластера, кроме виртуальных машин поддерживают отказоустойчивость других сервисов. К примеру, это может быть кластер из двух серверов поддерживающий SQL, а до кучи на нем может работать 2-3 виртуальных машины. В случае если производительности хватит на всех, это на 100% рабочая конфигурация.

Опять же немаловажно, что для техников уже работавших с Microsoft Failover Cluster кластеризация виртуальных машин будет таким же привычным делом как кластеризация файловой шары.

4. Система очень неприхотлива к оборудованию на котором она работает. Есть конечно жесткое требование по обязательной поддержке технологий Intel-VT или AMD-V процессорами в системе, но за исключением этого,система работает на любой платформе. Всё же системы Windows, чрезвычайно распространены в мире и количество драйверов под них не поддается исчислению.

5. Если рассматривать вариант лицензирования отказоустойчивого кластера Hyper-V, для которого требуется минимум две лицензии на Windows Server Enterprise Edition, то эти две лицензии также позволяют запустить 4 виртуальные машины с ОС Windows Server в виртуальной среде. В ситуации когда в компании работают только Windows это вполне актуально, при определенных расчетах может получиться так что сам Hyper-V вам достается бесплатно.

6. Hyper-V комфортно управляется средствами продуктов Microsoft System Center. С их помощью он умеет отправлять сообщения о проблемах, проводить резервное копирование, мониторить производительность, детально управлять обновлениями. Что приятно есть лицензия на SystemCenter для серверов, которая лицензирует все виртуальные машины физического сервера, на все компоненты SystemCenter.

7. В Hyper-V нормально реализована система сетевого подключения для виртуальных машин. Есть VLan, есть возможность надобавлять кучу разных сетевых карт. Конечно по сравнению с другими производителями это смотрится бедненько, но с другой стороны что еще надо?

 

В результате я вижу что заказчики имеющие чисто Microsoft среды с настроенным и работающим SystemCenter, остаются довольны продуктом. Он удовлетворяет все их потребности, не заставляя вносить в свою “исключительно MS” инфраструктуру чужеродные элементы, которые еще надо кому-то поддерживать. Опять же зачастую использование Hyper-V совпадает в таких ситуациях с лицензированием нелегальных Windows Server, что фактически означает что стоимость Windows 2008 EE уходит не только на сам Hyper-V, но и на легализацию существующих Windows.

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

четверг, 24 сентября 2009 г.

Обновление прошивки на RAID Adaptec 2й и 5й серии: проблема

На сайте Adaptec появилась информация о том, что обновление прошивки RAID контроллеров 2й и 5й серии (а это модели ASR-2405, ASR-2045, ASR-5405, ASR-5445, ASR-5805, ASR-5085, ASR-51245, ASR-51645, ASR-52445) с версии 16501 на более старшую может повлечь за собой недоступность данных (хотя все созданные ранее массивы будут иметь статус Optimal). Если у Вас на контроллерах установлена упомянутая прошивка, либо имеются массивы, которые были изначально созданы на прошивке версии 16501, настоятельно рекомендуется обратиться в техническую поддержку перед обновлением прошивки. Ну и если Вы уже обновили прошивку и доступ к данным пропал, то обращаться нужно туда же. В качестве быстрого решения возникшей проблемы можно прошить версию 16501 обратно – данные после этого станут доступны.

От себя могу сказать, что мы с такой проблемой до настоящего момента не сталкивались, что может свидетельствовать о том, что проблема встречается не так часто. Да и поскольку следующая после 16501 прошивка вышла еще в начале лета, а информация появилась только сейчас, вероятность не такая уж и большая. Но иметь в виду нужно и помнить про это важно.

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

вторник, 22 сентября 2009 г.

Intel RAID RS2BL080 6GB и 8 SAS 15k с разными FW контроллера

Компания Intel любезно предоставила нам этот контроллер на короткое время, за которое мы тестировали его в первую очередь на SSD Intel X-25 E, но также и сделали несколько тестов на обычных SAS дисках. К сожалению контроллер был у нас не очень долго и мне не удалось посмотреть все, что хотелось, но было сделано несколько полных прогонов с дисками SAS. При этом эти два прогона проходили на разных версиях прошивки контроллера сначала это была 649 версия, затем был сделан апгрейд в 673 версию и повторены часть из этих тестов.

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

Условия теста.

Из восьми SAS Hitachi 15k 146GB делался RAID 10, поскольку контроллер двух портовый половинки зеркала располагались на разных портах. Настройки Array на контроллере – следующие:

image

Собственно все настройки по умолчанию для 10 RAID.

Тест проводился Iometer’ом, профиль в обоих случаях был одинаковый. Вся нагрузка создавалась 4-мя Worker, глубина очереди каждого составляла 32. В результате как несложно посчитать: 128.

Результаты тестов

Потоковое чтение

Версия fw 649
image

Версия fw 673
image

Потоковое чтение – самый понятный показатель работы внутренних алгоритмов кэширования контроллера. Видно, что в более новой версии прошивки на большом блоке скорость существенно просела, причем пик достигается на 8кб а дальше идет резкий спад. Судя по дальнейшим результатам – 8кб размер блока КЭШ контроллера и поэтому тут и достигается максимальный результат. Также хочется отметить, что считалка у контроллера очень мощная, судя по тому что на маленьком блоке результат вплотную подбирается к 90 000 IOPS.

Случайное чтение

Версия fw 649
image

Версия fw 673
image

Здесь уже КЭШ не играет большой роли и результаты близки. Нужно отметить что IOPS на маленьком блоке упал почти в 2 раза.

Потоковая запись

Версия fw 649
image

Версия fw 673
image

На записи наоборот ситуация заметно улучшилась, потоковые операции упираются в потолок около 1,4 ГБ секунду, опять же очевидно влияние КЭШ. В целом новая версия прошивки больше радует глаз, чем предыдущая.

Случайная запись

Версия fw 649
image

Версия fw 673
image

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

Смешанная нагрузка – 70 запись, 30 чтение.

Версия fw 649
image

Версия fw 673
image

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

Вывод

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

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

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

пятница, 18 сентября 2009 г.

Новости – понятные и не очень.

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

Oracle не успев насладиться тесной дружбой с HP (первая версия Exadata)выпустил вторую версию Exadata, назвав ее “First Database Machine for OLTP”. Объявление громкое, про него и писали, и пытались заинтриговать. А в итоге получилась пачка обычных x86 серверов на (уже успевших набить оскомину) процессорах Intel Xeon серии 5500, объединенных в Oracle RAC. По сути, единственным новшеством стало использование в “Storage” узлах флэш-памяти для ускорения ввода-вывода. Заявляется производительность в 1млн IOPs (для full rack конфигурации с 14 Storage Servers), но результаты TPC-C обещают озвучить только к середине октября.  image Апологеты спарков конечно расстроены тем, что не попали на праздник, но удивительного в этом, на мой взгляд,  нет – предложить на текущий момент нечего. Эллисон в своем выступлении в основном бился против серверов IBM, которые давно уже занимают первую строчку в тестах TPC-C. Правда, при сравнении цен почему-то забыл упомянуть о том, что на один шкаф с экзадатой нужно еще заплатить больше 600тыс$ за Oracle RAC, тогда как в случае с IBM p595 этого не требуется. RAC это конечно очень быстро, масштабируемо, удобно и все такое, но если у уже заказчика есть работающая система на одном сервере, то будет довольно сложно убедить его променять эту одну машину на 22 маленьких, за которыми нужно следить (и, не приведи господи, у них там что-то в кластере “заклинит”). На мой взгляд, сказать что Oracle выпустил что-то радикально новое нельзя – тот же IBM вместе с FusionIO уже год назад демонстрировали фантастическую производительность (правда в лабораторных условиях). Интересно другое – как отразится объявление на HP? Или это еще один шаг Элиссона к тому, чтобы больше заинтересовать HP в покупке “железной” части SUN, про возможность которой продолжают возникать и циркулировать слухи? Время покажет.

Второе, совсем тихое событие – RAIDCore (от которого, немного попользовавшись, все почему-то старались избавиться, а последний владелец Ciprico так вообще обанкротился) может быть наконец обрел покой во владениях DotHill. Объявлен продукт под названием Virtual RAID Adapter (VRA) – программное решение для создания и управления RAID без использования аппаратных контроллеров. Продукт нацелен скорее на производителей плат – чтобы у них не было головной боли с тестированием драйверов под интегрированные контроллеры (ICH и т.д.). Насколько это будет востребовано для меня совершенно не ясно: с одной стороны, функционал RAIDCore несколько выше, чем у интегрированных контроллеров, с другой стороны, зачем метаться, если для бюджетного решения и то, что есть сейчас, тоже сгодиться, а на серьезных системах используются нормальные аппаратные контроллеры. Вот если бы поддерживались обычные HBA адаптеры, то интерес может быть и был бы – например для систем видеонаблюдения, где сейчас используются обычные HBA с десятками дисков, но без всякой защиты, а наличие такого программного RAID заметно повысит отказоустойчивость без серьезного удара по цене.

Ну и третье событие, хотя и не прозвучало очень громко, но зато вполне логично и понятно – NetApp расширил линейку систем хранения начального уровня, выпустив FAS2040.

imageКак и остальные системы 2000й серии, FAS2040 рассчитана на использование SAS и SATA дисков (до 12ти внутри контроллерного модуля), но расширяться может не только при помощи “классических” полок с FC или SATA дисками, но и уже чуть ранее объявленными SAS полками, так как на каждом контроллере есть по одному SAS порту. С одной стороны, система “помещена” между FAS2020 и FAS2050, но практически по всем характеристикам она превосходит и ту, и другую – расширяется до 136 дисков, имеет 8ГБ памяти, 8 портов ethernet и 4 порта FC (на два контроллера). Нет только возможности устанавливать в контроллер платы расширения, которая есть у FAS2050. Помимо объявления новой системы, сделано очень интересное предложение для покупателей FAS2020 – теперь они получат NFS и CIFS совершенно бесплатно (как и iSCSI). Видимо все больше ощущается конкуренция на рынках SMB со стороны Windows Storage Server, поэтому и было принято решение отдать CIFS в младшей системе даром, но наличие NFS и iSCSI (а также возможность получить двухконтроллерную систему) делает очень привлекательным использование FAS2020 не только для хранения файлов, но и в качестве хранилища для виртуальных машин VMware.

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

среда, 16 сентября 2009 г.

Полезная утилита Microsoft Diskpart

Полезность её в том, что она позволяет расширять NTFS диски в W2003, делается это нехитрым путем:

>cmd
>diskpart
>list volume
>select volume #
>extend

в этом случае все свободное место на диске, где находится том будет ему отдано. Требования: диск должен быть базовым, ФС – NTFS, место должно идти сразу за этим самым томом. Наиболее частое использование – расширение томов отданных с внешней дисковой системы. Поскольку в СХД проще недодать сейчас, чем отнять потом – команда пригодится.

также утилиту можно пользовать для просмотра ID дисков в системе:

>cmd
>diskpart
>list disk
>select disk #
>detail disk

Актуально для Microsoft Cluster Service.

Вообще утилита полезна не только этим, но это – то, чем приходится пользоваться часто.

UPD Спасибо, Александру в комментариях напомнил про выравнивание блока отступа в RAID массивах!

Проблема с выравниванием отступа (offset) старая и актуальная для 2003 сервера и младше. Заключается в том что выравнивание отступа начала файловой системы не совпадает с размером блока на массиве и поэтому все операции задействуют больше сегментов дисковой емкости чем могли бы в результате снижая быстродействие.

Описывать проблему долго и я не планирую здесь это делать, посмотреть как этот самый отступ менять можно в KB по ссылке ниже, применяя поиск по статье с ключевым словом “offset”. Для верности это значение проще всего ставить в 1024КБ. В 2008 сервере оно по умолчанию именно такое.

Ссылка на Microsoft KB по теме - №300415.

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

вторник, 8 сентября 2009 г.

6Gbps SAS в серверах IBM

6Gbps SAS диски уже некоторое время доступны к заказу вместе с серверами IBM, но вот сегодня были анонсированы и 6Gbps RAID контроллеры: ServeRAID M5014 и M5015. Оба контроллера имеют по 8 внутренних портов (2 miniSAS разъема) и поддерживают до 32х устройств, подключенных напрямую или через экспандеры. M5015 (на картинке) оснащен 512МБ кэш-памяти и поставляется вместе с батареей (BBU) для защиты кэша; M5014 имеет на борту 256МБ кэша и батарею к нему нужно будет докупать отдельно. Оба они построены на базе 800МГц процессора PowerPC  c контроллером LSI SAS2108 RAID-on-Chip – IBM продолжает использовать контроллеры LSI, в данном случае это, как я понимаю, практически полные аналоги MegaRAID SAS 9260-8i.

IBM ServeRAID M5015 SAS/SATA Controller

На данный момент контроллеры поддерживаются в серверах IBM x3400M2, x3500M2, x3550M2 и x3650M2 (т.е. все новые двухпроцессорные модели на “нехалемах”). Ранее мои коллеги уже приводили результаты тестирования аналогичного контроллера от Intel вместе с SSD и результаты очень впечатляют. Так что если Вам нужна высокая производительность дисковой подсистемы сервера – можно довольно успешно комбинировать новые контроллеры вместе с уже поставляемыми для этих серверов 50GB High IOPS SSD.

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

четверг, 3 сентября 2009 г.

Veeam Backup & Replication 4.0

Что-то немного позавчерашние новости получаются, но все руки не доходят..

Буквально несколько дней назад была анонсирована новая версия Veeam Backup. Изменения во многом ориентированы на использование в vSphere:

  • Поддерживается технология vStorage API, который пришел на смену VCB (VCB, впрочем также поддерживается). Поддержка vStorage необходима, например, для бэкапа FT виртуальных машин.
  • Полностью поддерживаются thin-provisioned диски, что существенно может сократить время резервного копирования и восстановления.
  • Поддерживается отслеживание измененных блоков, что также сокращает время инкрементального резервного копирования.
  • Можно делать “горячую” репликацию дисков работающих VM на удаленную площадку.
  • Полная поддержка PowerShell дает возможность всю работу “загнать” в скрипты.
  • Логи теперь автоматически исключаются из бэкапов и репликации для сокращения времени и экономии трафика.
  • Вместо того, чтобы на удаленную площадку посылать через плохой канал начальную реплику, теперь можно сделать ее локально и физически перевезти на удаленный сайт.
  • Улучшенный функционал в плане управления заданиями (в т.ч. возможность временной отмены заданий).

Полный список изменений можно прочитать тут.

Благодаря возможности делать репликацию каждые несколько минут, мы получаем близкую к CDP защиту данных. Я и раньше всегда рекомендовал Veeam Backup совместно с VMware ESX/ESXi, но теперь это становится уже практически “must have”.

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

VMware ThinApp против…

Tolly Group на днях опубликовали новое сравнение: “Application Virtualization: VMware ThinApp 4.0 versus Microsoft App-V 4.5 CU1 and Citrix XenApp 5.0”. Указанное сравнение не включает тестирование производительности, а оценивает, что называется, общие впечатления: требования при установке продукта, развертывание клиентов, процесс “упаковки” приложений, предоставление on-line и off-line доступа к приложениям. С одной стороны, статья подготовлена по заказу VMware, поэтому довольно просто угадать лидера сравнений :) Кроме того, XenApp наверное не совсем корректно сравнивать с ThinApp – все-таки это продукты немного разных категорий, хотя возможность стриминга приложений есть и там, и там. С другой стороны, если интересует именно “упаковка” приложений для доступа как по сети, так и, например, с USB флэшек, то по простоте и универсальности обойти ThinApp пока никому из конкурентов не удается: максимально упрощен как сам процесс упаковки приложений (а главное, контроль доступа к приложениям), так и сам доступ со стороны клиента – не требуется ни установки, ни настройки никаких дополнительных приложений. Стоимость VMware ThinApp на текущий момент составляет 5000$ за комплект для 50ти пользователей и по 39$ дополнительно за каждого следующего пользователя (без учета стоимости поддержки).

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

среда, 2 сентября 2009 г.

IBM BladeCenter Virtual Fabric

У HP есть замечательные коммутаторы для 7000го и 3000го шасси - HP Virtual Connect Flex-10.  “Замечательность” данного продукта состоит в том, что он позволяет создавать до 4х виртуальных FlexNIC на каждый 10Гбит порт, при этом, пропускная способность каждого FlexNIC может быть выбрана нужная пользователю (с шагом 100Мбит). Такое решение замечательно подходит для виртуальных сред (vSphere, Hyper-V), где крайне желательно иметь больше обычных двух сетевых линка на сервер-лезвие.

До недавного времени IBMу было фактически нечего предложить “в отместку”, но ситуация меняется и для BladeCenter-H/HT анонсировано решение IBM BladeCenter Virtual Fabric, базирующееся на коммутаторах BNT 10-port 10Gb Ethernet Switch Module, картах Emulex Virtual Fabric Adapter (которые могут быть установлены например в лезвия HS22) и BladeCenter Open Fabric Manager (через который осуществляется управление). Коммутатор имеет 10 внешних 10Гбит портов, за счет чего меньший oversubscription нежели у HP – 14:10 у IBM против 16:9 у HP. Каждый 10Гбит канал от сервера к коммутатору также может быть разделен на 4 виртуальных и тоже с шагом 100Мбит. Так как и коммутатор, и адаптер готовы к поддержке FCoE, то немного позднее можно будет наряду с vNIC использовать и FCoE для подключения к СХД.

Указанное решение позволяет получить отличную платформу для развертывания виртуальных сред, а также позволяет подготовится к явно грядущему наступлению FCoE.

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

пятница, 28 августа 2009 г.

Intel SSD x25-e и Intel RAID RS2BL080

Продолжая тему SSD и их работы в RAID, надо отметить что пока что (на мой взгляд) не было контроллера который давал адекватную производительность во всех ситуациях с SSD. Также большой головной болью было то, что при отключении КЭШа SSD дисков производительность системы значительно падала, тогда как его требуется выключать для создания отказоустойчивых конфигураций.

Вот и получается – хочется чтобы все работало быстро, включай КЭШ диска. Но если вдруг выключиться электричество или будет еще какой сбой, все данные находящиеся в этом КЭШе потеряются. С другой стороны выключая КЭШ мы получали просадку по производительности (подробнее можно посмотреть в предыдущем материале про SSD и контроллеры LSI).

Теперь непосредственно, что привело к написанию этого материала. Intel любезно предоставил нам в тест контроллер Intel RAID RS2BL080, который интересен тем, что он рассчитан на 6ГБ SAS (обратная совместимость с SAS 3GB и SATA присутствует), в результате чего имеет полностью переработанную архитектуру. Для начала мы решили посмотреть контроллер в работе с SSD, чтобы посмотреть на что он способен при максимально быстром back-end (дисках), результаты тестов и будут представлены ниже.

Контроллер Intel RAID RS2BL080

RS2BL080_lg
Intel RAID RS2BL080 он же LSI MegaRAID 9260-8i

Строго говоря контроллер произведен компанией LSI, Intel же OEMит их. В контроллере 8 портов 6Gb/s SATA/SAS, 512МБ памяти и процессор LSISAS2108 (6Gb/s RAID-on-Chip - 800MHz PowerPC). Выглядит вполне обычно.

Судя по маркетингу LSI максимальная пропускная способность чтения около 2,9ГБ/сек, а записи 1,8ГБ/сек.

Описание на сайте Intel.
Спецификация на сайте Intel.
Спецификация на сайте LSI.

Тесты с SSD

Было решено в первую очередь проверить две разные конфигурации:

1. 8 штук SSD Intel x25-e в RAID 5, КЭШ контроллера включен, КЭШ дисков выключен. Общий смысл данного теста был посмотреть, как себя покажет конфигурация собранная из расчета компромиссного соотношения цена/объем. Также немаловажно и то, что КЭШ дисков был отключен, в реальную работу не стоит ставить диски с включенным КЭШ, слишком велики риски потери информации.

2. 8 штук SSD Intel x25-e в RAID 10, КЭШ контроллера включен, КЭШ дисков выключен. Также было решено проверить R10 для оценки разницы в производительности относительно R5.

Ниже представлены скриншоты настроек.
Тест делался по обычной схеме с Iometer’ом.

New Bitmap ImageНастройки для теста в R5

test Настройки для теста в R10

Результаты

Последовательное чтение.

Raid5

image

Raid10

image

Чрезвычайно впечатляющее начало 160 000 IOPS на чтение, эти цифры соизмеримы с характеристиками производительности дисковых систем среднего уровня. С той лишь разницей, что на дисковой системе с обычными дисками, таких цифр можно достичь только из чистого КЭШа, а здесь эти цифры получены на LUN в 200GB. Фактически этот результат показывает производительность контроллера, для сравнения LSI 84016E давал в пике около 40 000 IOPS, Adaptec 5805 около 50 000 IOPS, здесь же мы получили 160 000 IOPS на маленьком блоке. Очень круто. Руки чешутся протестировать на нем обычный SAS, чтобы понять даст ли такой контроллер роста производительности с обычными дисками.

Кстати кроме IOPS не менее интересно что контроллер достиг уже 1200 МБ/сек. У предыдущего LSI этот потолок был около 800МБ/сек.

Случайное чтение.

Raid5

 image

Raid10

image

Результат очень достойный, для полностью случайной нагрузки также отличный результат. Тот же потолок в 1200 МБ/сек, достигается здесь несколько позже чем при последовательном чтении, что в общем естественно. Для сравнения IOPS у LSI 84016E было примерно столько же, у Adaptec 5805 в Raid5 чуть больше (правда с включенным КЭШ дисков .) ).

Отличные результаты, на уровне лучших что я видел для такого количества SSD при такой нагрузке.

Последовательная запись.

Raid5

 image

Raid10

 image

Исключительные результаты, видно что контроллер работает по максимуму и вычислительной мощности ему хватает с лихвой. При всем при этом, что интересно в RAID 5 контроллер пробил планку в 1200МБ/сек и уперся уже в 1400МБ/сек. В RAID 10 такого не наблюдается, видимо по причине меньшего количества конечных дисков на которые ведется запись. Тест опять же наглядно показывает что подопытный контроллер чрезвычайно мощный.

Что интересно, так называемого, RAID 5 penalty не наблюдается. По идее мы должны были бы видеть некоторую просадку по производительности в RAID 5 , относительно RAID 10.

Случайная запись.

Raid5

 image

Raid10

image

Левая часть графиков где отражены IOPS соответствует высоким ожиданиям, динамика графиков с точностью повторяет такую в предыдущих тестах, результаты получаются лучше чем и у LSI 84016E и у Adaptec 5805. Adaptec 5805 проигрывает где то около 20% в RAID5 и около 30% в RAID10, LSI 84016E проигрывает около 20% в RAID10 результатов эквивалентных тестов в RAID5 у меня нету.

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

Также надо отметить, что есть подозрение что такое поведение массива обязано больше не контроллеру а дискам и их собственным алгоритмам записи и выстраивания очереди. Любопытно посмотреть аналогичные результаты при включеном КЭШ дисков (собственно именно эти тесты сейчас у нас и идут).

33% чтение, 100% случайные операции.

Raid5

 image

Raid10

 image

Комментировать особенно нечего, случайная запись задает тон результатам. Они в точности повторяют динамику случайной записи.

Типовые профили

Raid5

Access
Specification
Name
IOps Read IOps Write IOps MBps Read MBps Write MBps ART (ms) ART-read (ms) ART-write (ms)
File Server 7 938,72 6 349,31 1 589,41 85,82 68,62 17,20 4,03 4,78 1,04
Web Server 15 791,47 15 791,47 0,00 242,30 242,30 0,00 2,03 2,03 0,00

Raid10

Access
Specification
Name
IOps Read IOps Write IOps MBps Read MBps Write MBps ART (ms) ART-read (ms) ART-write (ms)
File Server 17 184,08 13 750,53 3 433,55 185,72 148,68 37,04 1,86 2,02 1,21
Web Server 20 511,35 20 511,35 0,00 313,48 313,48 0,00 1,56 1,56 0,00

В качестве сравнительной шкалы приведены результаты двух типовых тестов, отметить хочется то, что при очень высоких результатах время ответа (ART) сохраняется на рекордно низком уровне 1-4 ms. В этих же результатах видно что RAID 10 благодаря более высоким результатам на записи показывает лучшие результаты.

Выводы

Что хочется сказать в итоге, контроллер судя по этим результатам получился исключительно мощный, руки чешутся сделать тесты на 15k SAS дисках (я думаю сделаем на следующей неделе), вероятно контроллер и на них даст лучшую производительность чем его текущие конкуренты (тот же Adaptec 5805).

Касаемо текущей конфигурации на SSD, пожалуй её можно рекомендовать для любой интенсивной дисковой нагрузки. Там где будет преимущественно случайная запись большим блоком результат не будет радовать, с другой стороны это одна из самых синтетических нагрузок.

Доступность и стоимость контроллера пока не ясна, как я уже писал выше, нам он достался в единственном экземпляре и реальных цен в РФ я не видел. Судя по всему он должен быть в одной ценовой группе с Adaptec 5805 и аналогичными 8 портовыми LSI.

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