вторник, 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.

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

понедельник, 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 делают его приобретение весьма заманчивым. Особенно если в хозяйстве уже есть какая-то “старая” система хранения и хочется не только добавить еще одну систему, но и унифицировать управление.

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

среда, 9 декабря 2009 г.

Настоящий мужчина!

 imageВ последнее время я как-то пристрастился смотреть бои без правил. Не знаю уж почему, но динамики там точно больше, чем у наших футболистов. Деньги бойцы за бои наверное получают неплохие, но и порекламировать что-нибудь не гнушаются. Зачастую наносят логотипы на одежду или даже на спину краской. И вот, вчера, щелкая пультом, натыкаюсь на соревнования в стиле “сборная России против всех и вся в разных видах единоборств”. И попадаю аккурат на тайский бокс. Не сказал бы что бой получился очень зрелищным, но что-то в нашем бойце внимание привлекало. Уж очень раскраска его труселей что-то напоминала. Что-то такое прямо из детства… Пригляделся – и точно, разукрашены они как банка сгущенки! А вот, точно, даже и надпись имеется, аккурат на причинном месте - “СГУЩЕНКА”. Дальше без смеха уже смотреть бой не мог. Если бы соперник читал по-русски, бой наверное мог бы закончится гораздо быстрее (но наш все-таки победил). 

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

вторник, 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. Если сломалось все так, что данные уже недоступны, не делайте резких движений и обратитесь к профессионалам. Найти таковых не представляет особенных проблем – даже если Вы находитесь вдали от двух столиц, общение можно свести к пересылке по почте и телефонному общению. Поверьте, почтовые затраты померкнут на фоне стоимости работ по восстановлению. Если есть возможность, сделайте посекторную копию всех дисков и экспериментируйте уже “на кошках”.

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

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

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

Еще про мотивацию сотрудников

Оказывается в NetApp работают веселые ребята: 

http://blogs.netapp.com/dave/2009/11/always-bet-against-your-employees.html

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

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

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

вторник, 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 экспандеров не только не противопоказано, а вполне оправдано в подавляющем большинстве случаев!

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

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

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

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

image

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

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

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

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

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

понедельник, 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 систем имеют довольно много шансов занять вполне заметную нишу. Причем, от чисто вычислительных задач интерес постепенно будет смещаться в сторону бизнес-приложений (СУБД и т.п.).

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

вторник, 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.

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

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

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

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

 

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

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

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

"граматнасть"

Читаю очередное письмо, пришедшее  на email, и понимаю, что что-то меня в нем смутно тревожит, но что именно сразу понять никак не могу. Вроде бы все верно написано, а вот что-то не так! Но тут взгляд падает на подпись и все сразу становится на свои места. Смеялся долго. А написано там было просто:

“С уважением директор группы кампаний ********”

Чего же ждать, если руководитель группы “кампаний” не в состоянии правильно написать это слово? Не поленился сходить на их сайт – “компания” перемешана с “кампанией” в совершенно случайном порядке. Может быть это корпоративное? Кофе, в соответствии с “последними инструкциями ВЦСПС” уже стал непонятного рода, с йогуртом вообще мрак и ужас. Что же дальше нас ждет?! Куда катимся?

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

четверг, 1 октября 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’ы, но тот функционал, который предоставляется, того стоит. Продажей этих систем занимаемся в том числе и мы, так что – милости просим!

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

четверг, 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 прошивка вышла еще в начале лета, а информация появилась только сейчас, вероятность не такая уж и большая. Но иметь в виду нужно и помнить про это важно.

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

пятница, 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.

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

вторник, 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.

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

четверг, 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”.

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

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$ дополнительно за каждого следующего пользователя (без учета стоимости поддержки).

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

среда, 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.

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

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

Для владельцев CLARiiON, использующих iSCSI и vSphere

Если Вы используете iSCSI на EMC CLARiiON для подключения к vSphere и испытываете проблемы с производительностью, то проблема в том, что кларионы идентифицирует iSCSI сессию только по IQN, что вызывает многочисленные log-in/log-off и заметно снижает скорость. Более подробное описание проблемы и, что более важно, ее временное решение (до исправления FLARE) находится тут.

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

Обновления NetApp

Новости, правда, уже пару дней как отшумели, но раньше что-то не доходили руки :)

Объявлено о выходе 8й версии ONTAP, ключевая особенность – наконец состоялось (худо-бедно) слияние “классической” версии и ONTAP GX. Слияние обещали уже лет 5, но вот теперь оно свершилось. Почему “худо-бедно”? Несмотря на то, что ONTAP теперь один, все равно приходится выбирать, как он будет работать – в “7 mode” или “claster mode”. Классический вариант 8ки практически эквивалентен версии 7.3.1, но из-за слияния {временно} лишен IPv6 и SnapLock. С другой стороны, появились 64бит агрегаты, что конечно будет на руку всем, кому было мало 16ТБ. Но и здесь не обошлось без ложки дегтя – для младших систем размер агрегата увеличился всего до 40ТБ, а максимальные 100ТБ можно получить только на старших 6070 и 6080 (из-за ограничений, вызванных объемом памяти). Смешение 32х битных (уже имеющихся) и 64х битных (новых) агрегатов может повлечь неприятные моменты – в частности, если Вы купили новую систему под Volume SnapMirror и сделали в ней 64х битные агрегаты, то снап-миррор работать не будет. Превратить один агрегат в другой без миграции данных на свободное место нельзя.

Вторая важная новость - NetApp начинает предлагать SAS полки для своих систем (всех, кроме самой младшей 2020). Полка сейчас только одна – DS4243, занимает 4U в стойке и может вмещать до 24х дисков SAS или SATA(если быть точнее, то заказать можно либо 12, либо 24 диска). Диски внутри полки могут быть только одного типа, поэтому поставить 12 SAS и 12 SATA дисков не получится.

Полка, как я понимаю, традиционно изготавливается на заводах Xyratex и очень сильно напоминает OneStor SP1424s, однако интерфейсные модули стоят другие и обеспечивают дополнительный канал управления через ethernet порт. Благодаря этому каналу можно управлять экспандером (перезагружать и т.п.), но нужно будет выделить один из портов ethernet на каждом контроллере под это дело (пока на новых системах не будет отдельного порта). Стекировать можно до 10 полок, получая до 240 дисков в стеке (нужно помнить, что количество дисков на систему не поменялось, поэтому для младших систем ограничения будут другие).

Также был анонсирован кэширующий модуль PAM II объемом 256ГБ и 512ГБ. Теперь для старших систем можно получить до 4ТБ кэша (чтения). Про него имеет писать с графиками и результатами тестов, соответственно, все это можно уже прочитать у самих нетаповцев.

Аппаратные обновления поддерживаются в ONTAP 7.3.3, которая ожидается в декабре 2009 (если я правильно помню). Также в этой версии будет возможность прозрачной миграции данных между системами с включенным MultiStore (для NFS и iSCSI) – NetApp Data Motion, приложения, при этом, не потребуется останавливать. Можно сказать, что это некий аналог Vmware Storage vMotion.

Все вышесказанное относится конечно и к IBM N series (анонсы должны быть чуть позднее).

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

вторник, 25 августа 2009 г.

IBM DS5020 приходит на смену “старичку” DS4700

Дисковая система IBM DS4700 уже несколько лет является боевой лошадкой для тех, кому нужна довольно производительная и расширяемая СХД среднего класса не с заоблачной ценой. Но вот и пора на покой – на смену приходит новый игрок – IBM DS5020. Анонс, традиционно, датирован вторником (сегодняшним числом).

imageЧто же нас ждет? Неожиданных новостей не будет – практически все уже видели у “старшего брата” – DS5100/5300. В базе система DS5020 оснащена 4мя портами FC 8Gbit (по два на каждый контроллер). При желании, можно дополнительно установить либо еще 4 порта FC 8Gbit, либо 4 порта iSCSI 1Gbit. Это избавляет нас от необходимости использовать отдельные (и требующие соответствующей настройки) iSCSI-гейты для подключения серверов, которым нет особой нужды в FC. Диски поддерживаются SATA (750GB и 1TB) , FC (146/300/450GB 15k) и FDE (с поддержкой шифрования – 146/300/450GB 15k). Поддержка SSD осталась в старшей серии, что наверное логично (в первую очередь из-за цены SSD – уж если есть бюджет на них, то и на DS5300 можно найти). В плане кэша также есть выбор – 2 или 4GB на систему. Т.е. хотя и разграничения по моделям и нет, но “болезненный” выбор необходимых опций при начальном заказе остался - дополнительные порты и расширение кэша доступны только при изначальном заказе, но не как апгрейд. Одно из новшеств DS5100/5300, перекочевавшее в DS5020, состоит в том, что защита кэш памяти не ограничивается установкой батарей, а при отключении питания происходит “сброс” содержимого кэша на флэш-память, что обеспечивает защиту кэша даже при долговременном отключении системы (или при неполной зарядке батарей). В контроллерной полке, как и в DS4700 можно установить до 16-ти дисков, а вся система расширяется до 112 дисков. Полки расширения используются новые EXP520, но и “старые” EXP810 также можно подключить (правда требуется соответствующая лицензия). Бэкэнд остался 4х гигабитным. Но исчезла лицензия, позволяющая смешивать в одной системе FC и SATA диски – теперь это можно делать совершенно спокойно (диски, как и прежде, можно “смешивать” по собственному желанию, без каких либо ограничений). Кроме того, добавление первой EXP520 не требует никаких лицензий. Лицензируется подключение дисков с 33 по 64го, при подключении более 64х дисков потребуется еще одна лицензия. Минимальное число Storage Partitions, как и прежде, 2 и расширяется до 128ми степенями двойки (4, 8, 16, 32, 64, 128). Вот собственно и все новости – внешне система практически не отличается от DS4700 (спереди только надписью, а сзади – небольшим внешним отличием контроллеров).

Основные характеристики по сравнению с DS4700 мало изменились: поддерживаются RAID1,3,5,10,6; в одной RAID-группе RAID10 можно использовать до 112 дисков, в остальных типах RAID – до 30ти дисков; поддерживаются такие возможности как создание мгновенных снимков (FlashCopy), клонов (VolumeCopy) и репликация на удаленный массив (Enhanced Remote Mirroring). Производительность системы заметно увеличена (результаты пока официально не опубликованы, но обещают до 50% прироста). Фактически, получили новую “рабочую лошадь” взамен старой.

А что же все-таки не получили, хотя было бы очень полезно? Есть и такое:

  • установка дополнительных портов по мере необходимости (EMC вон уже давно это умеет);
  • расширение кэша как апгрейд;
  • поддержка SSD – не больно и хотелось, а, положа руку на сердце, и не нужно (с технической точки зрения), но “толпа жаждет”;
  • расширение возможностей VolumeCopy и FlashCopy;
  • FCoE – хотя и тоже пока не актуально, но тоже было бы громким шагом.
Понравился пост? Подпишись через RSSRSS, EmailEmail или twitter!

понедельник, 24 августа 2009 г.

А нужна ли финансовая мотивация?

На TED'е еще одно отличное выступление: Dan Pink рассказывает про негативное влияние финансовой мотивации при решении сложных задач. Да-да! Это не опечатка - ряд исследований показывает, что деньги, как награда за достижение цели, могут не столько улучшить результат, сколько ухудшить его! Мотивация хорошо работает для простой (почти механической) работы, но, как только требуется применить интеллект, призрачная награда начинает все больше отдалять цель.



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

CNA - в массы … но пока еще не скоро.

Qlogic объявили о начале отгрузок второго поколения CNA адаптеров – серию 8100. Ключевые отличия – поддержка PCI-express x8 версии 2.0 и теперь вся реализация “упрятана” в единственный чип. Как следствие, карты получились очень экономичными по питанию – тепловыделение всего 7W . Заявлена производительность в 250.000 IOPs на порт (платы как одно-, так и двухпортовые). iSCSI поддерживается через программный инициатор, что несколько ограничивает применение на высоких скоростях (впрочем, для этого данные платы и не предназначены).

image

Подключение – через SFP+, а варианты поставки есть как без SFP+ модулей (для twin-ax кабелей), так и с модулями под SR и LR оптику. На текущий момент можно уже строить решение целиком под FCoE – коммутаторы Cisco Nexus 5000 (или Brocade 8000), дисковые системы от NetApp (или их аналоги - IBM N Series) уже сейчас можно заказать с FCoE интерфейсами (кроме того, имеющиеся FC системы можно подключить к коммутаторам в специально отведенные порты). Таким образом (если задаться целью), уже сейчас можно получить инфраструктуру завтрашнего дня. Однако, по различным оценкам (как аналитиков, так и самих заказчиков) реальных внедрений стоит ожидать в 2011-2012 годах.

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

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

Аппаратная платформа от Falconstor

Компания 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 там просто некуда подключить).

imageНасколько это хорошее решение сказать сложно – с одной стороны, все компоненты поставляются "из одних рук и это сильно облегчает жизнь при возможных проблемах. С другой стороны, реализация всего функционала СХД на той же системе, на которой работает сам NSS, может существенно влиять на производительность. Ограниченные возможности по подключению сторонних дисковых систем не добавляют решению “плюсов”. Но вот однако, если вместо NSS использовать VTL – получается вполне привлекательный вариант, так как перестает болеть голова о выборе аппаратной платформы для виртуальной ленточной библиотеке.

Выпуск NSS HC никак не ограничивает поставки чисто программной части NSS –этот продукт по прежнему можно спокойно приобретать и использовать с оборудованием сторонних производителей (как и предполагалось изначально).

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

VMware Acceleration Kit: не потратил - значит заработал

Сегодня пару слов о банальном, но, увы, про это часто забывают.

Ни для кого не секрет, что скидки на системный софт (к которому относится и 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.

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

понедельник, 10 августа 2009 г.

LUN, RAID array и другие…

В последнее время все чаще возникают вопросы про то, как нужно создавать RAID-массивы и, как следствие, возникают недопонимания и разночтения про такие понятия как LUN и RAID. Разночтения возникают из-за того, что контроллеры разных производителей работают немного по-разному (в плане логической организации) и человек, привыкший работать например с контроллерами Adaptec, имеет сложности, объясняя владельцу контроллера LSI, что именно нужно сделать.

Начну с очевидного: RAID-контроллеры позволяют создать несколько логических дисков “поверх” имеющихся физических дисков. Обратите внимание, что “логические” они именно с точки зрения RAID-контроллера, так как сервер видит их как вполне себе отдельные физические диски. Скажем, если к нашему абстрактному RAID-контроллеру подключено 8 дисков по 1ТБ и сделано два логических диска на 1ТБ и на 7ТБ, то операционная система сервера будет “думать”, что к серверу подключено два диска – на 1ТБ и на 7ТБ (а то, что дисков на самом деле 8, будет “скрыто” за RAID-контроллером).

RAID-LUN-01

Часто для обозначения этих самых “логических” дисков применяется термин LUN (его можно читать как Logical UNit, но правильнее – Logical Unit Number, так как исторически этот термин применялся именно для нумерации дисков на SCSI шине).

RAID-контроллеры позволяют по-разному создавать логические диски “поверх” физических. Одни (3Ware, старые контроллеры LSI) позволяют создать RAID-массив из произвольного числа дисков и потом разделить его на несколько частей (именно это чаще всего имеют в виду, когда говорят про “разбиение массива на LUNы”):

RAID-LUN-02

Другие контроллеры (новые LSI, Adaptec), напротив, не позволяют делить созданные RAID-массивы на части, но зато позволяют на одних и тех же дисках создать несколько массивов (причем, массивы могут быть созданы разного уровня):

RAID-LUN-03

Во втором случае, говорить про “нарезание” LUNов на массиве конечно не совсем корректно (и зачастую сильно затрудняет понимание), но общий смысл остается неизменным – в обеих случаях мы создаем несколько логических дисков на одном и том же наборе дисков физических. Именно так и следует понимать фразу наподобие “выделите под эти данные отдельный LUN”. Речь идет только о том, что для обсуждаемой задачи не требуется весь объем жестких дисков, входящих в RAID-группу, и следует создать средствами контроллера логических диск нужного размера, независимо от того, как это реализовано в используемом контроллере.

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

вторник, 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!