В инфраструктуре из нескольких серверов задача миграции виртуальных машин между гипервизорами если и возникает, то редко и разово. А вот если счет серверов идет на десятки, то вероятность параллельного использования двух гипервизоров весьма высока - кто-то это делает для экономии на лицензиях, кто-то чтобы не класть все яйца в одну корзину. И миграция виртуальных машин между Hyper-V и VMware может оказаться непростой задачей.
Уже некоторое время существует решение для ускоренной миграции из VMware в Hyper-V, разработанное с участием NetApp - MAT4Shift. Основная сложность в миграции - необходимость конвертировать диск с данными, а это требует существенных затрат времени (и ресурсов СХД). Если использовать только MAT (Microsoft Automation Toolkit), миграция 1ТБ диска может занять несколько часов. MAT4Shift за счет использования технологии FlexClone в СХД (да-да, конечно требуется не только утилита, но и СХД NetApp FAS) позволяет радикально сократить время миграции. Скорость возрастает, так как фактически не происходит конвертации данных, изменяются только заголовки и метаданные, после этого VMDK “превращается” в VHDX диск. Утилита также удаляет vmware tools и вносит необходимые изменения в настройки сетевых интерфейсов и VLAN. Время миграции виртуальной машины из VMware в Hyper-V сокращается от нескольких часов до всего нескольких минут.
Несмотря на достигнутые результаты, хочется еще, как минимум, конвертировать VM и из Hyper-V в VMware. Чтобы закрыть вопрос миграции в гетерогенной виртуальной среде, NetApp выпустил отдельный продукт - NetApp OnCommand Shift. Именно благодаря ему можно без лишних затрат времени и при минимальном участии администраторов производить миграции VM из VMware в Hyper-V и наоборот.
Как же осуществляется миграция?
ПО собирает данные о настройках виртуальной машины, которые необходимо будет воспроизвести после миграции.
Создается клон виртуальной машины (технология FlexClone в СХД NetApp FAS). Независимо от размера диска VM, процесс клонирования происходит практически мгновенно.
Происходит автоматизированное удаление утилит (VMware tools или Hyper-V Integration tools).
Дальше некоторое время требуется для настоящей магии - замены метаданных и заголовков в снимке диска (VMDK/VHDX). Сами данные не изменяются, а так как объем метаданных сравнительно небольшой, время конвертации диска мало зависит от размера исходных данных.
Если необходимо, устанавливается новый набор утилит.
Переносятся настройки, сохраненные на первом этапе. После миграции будут сохранены все сетевые настройки, подключения к VLAN и названия сетевых подключений.
Если нужно перенести не одну, а сразу несколько VM, автоматизировать процесс поможет модуль OnCommand Shift PowerShell.
Еще одним преимуществом OnCommand Shift является то, что у нас нет необходимости в двукратном увеличении дискового пространства - данные в новом формате занимают те же самые блоки, что и данные до миграции. Это может быть достаточно важно при планировании массовых миграций.
Поддерживаемые гипервизоры: VMware ESXi 5.0 и выше, Microsoft Windows Server 2008R2 Hyper-V и выше. На NetApp должна быть установлена Clustered Data ONTAP 8.2 и выше, также потребуется создать виртуальную машину (требования самые скромные), в которой и будет выполняться OnCommand Shift.
Да, все это бесплатно, но работает только для владельцев СХД NetApp - остальным придется либо тратить на миграцию больше времени, либо искать альтернативы (про которые я, впрочем, пока не слышал).
Контейнеры уже наделали много шума за последний год — в свое время даже про виртуализацию говорили меньше. Популярность их, безусловно, не случайна — многие решения можно построить на основе микро-сервисов. Многие разработчики поддерживают такой подход (и именно от них идет столько шума про контейнеры). Той изоляции, которую предоставляет виртуализация уже недостаточно — слишком много накладных расходов, чтобы изолировать каждый сервис, контейнеры обеспечивают гораздо большую эффективность в плане затрат ресурсов.
Многие наверное еще осенью слышали обещание Microsoft о грядущей поддержке Docker в новой версии Windows. И вот, пришла пора узнать подробности — вчера в Microsoft было сразу два анонса, имеющих непосредственное отношение к контейнерам.
Во-первых, это контейнеры Hyper-V. Благодаря интеграции с Docker, код, работающий в рамках одного контейнера, изолирован от процессов в операционной системы и процессов в других контейнеров. Hyper-V контейнеры можно будет развертывать как обычный Windows Server контейнер, так и в виде виртуальной машины Hyper-V — довольно интересная опция, которая может стать аргументом для принятия технологии корпоративным сектором. Управление обоими видами контейнеров осуществляется через Docker.
Во-вторых, объявлено о еще одной редакции Windows Server. Это минифицированная операционная система с говорящим за себя названием Nano Server. В результате масштабного рефакторинга существенно сокращен размер ядра, а сама система поддерживает удаленную установку и управление. Nano Server оптимизирован для облачных вычислений и DevOps разработки. Наконец-то нам обещают меньше патчей и апдейтов, а также быструю перезагрузку. Редакция Nano Server будет доступна уже в следующем релизе Windows Server, поэтому ждать остается не так уж и долго.
Пользователь сможет устанавливать только те компоненты, которые действительно нужны. Результат от таких оптимизаций весьма многообещающий — на текущий момент декларируется:
уменьшение размера VHD-файла на 93%
потребуется на 92% меньше патчей — (возможно речь идет о потенциальном количестве, за счет сокращения числа устанавливаемых сервисов)
снижение числа перезагрузок на 80%
Чтобы все это достичь пришлось избавиться от GUI, отказаться от поддержки 32 битных приложений, MSI и от целого ряда других, стандартных для Server Core, компонентов. В том числе, нет поддержи локальной авторизации и RDP — все управление осуществляется только удаленно через PowerShell и WMI. Для обеспечения удобства управления нас ждут изменения в PowerShell — будут поддерживаться, например, передача файлов и удаленная отладка. Кроме того, планируется представить новые web-утилиты как замену локальных инструментов управления.
Так как Nano Server это именно переработанная версия Windows Server, то полная совместимость с API (в рамках оставшихся в Nano Server компонентов) упростит разработку нового ПО. Visual Studio будет полностью поддерживаться, так что экосистема не должна оказаться пустой.
Например, в Chef плотно занимаются интеграцией с Nano Server, заявляя о том, что новая платформа (Nano Server плюс автоматизация от Chef) станет отличным решением для разработки в стиле DevOps.
Само собой, Nano Server будет и отличной базой для развертывания на нем контейнеров Windows Server и Hyper-V контейнеров. В мире Linux аналог уже доступен — Red Hat Enterprise Linux Atomic Host.
Уже в конце апреля, на конференции Build 2015, можно будет увидеть контейнеры Windows «живьем».
Вот, теперь можно и начать разворачивать виртуальные машины!
В 15 минут конечно не уложились и попутно настроили десяток серверов, но зато "бесплатный" гипервизор и вся инфраструктура на базе Microsoft. Это конечно все сарказм и шутки - документ на самом деле интересный и полезный. Стоит прочитать или хотя бы помнить, что он существует.
Если VMware предлагает EVO:RAIL с тем, чтобы пользователи могли сами развернуть всю инфраструктуру максимально быстро при минимальных знаниях, то Microsoft, по всей видимости, дает возможность партнерам заработать на сервисе и продавать заказчикам услуги по развертыванию. Это конечно имеет смысл, но вот вопрос что выберет партнер - развернуть за 15 минут VMware и оставшееся время потратить на обучение сотрудников заказчика, либо потратить день на развертывание Hyper-V?
Huawei и DataCore объявили о партнерстве в области Software Defined Storage и hyperconverged систем.
DataCore Software, как мне кажется, не очень хорошо известны на российском рынке, но эта компания очень давно работает на рынке программных реализаций систем хранения и ее продукт SANsymphony активно конкурирует с такими системами как, например, Falconstor NSS.
Конвергентная система состоит из серверов Huawei FusionServer RH с предустановленным программным обеспечением DataCore SANsymphony и поддерживает различные гипервизоры (Hyper-V и VMware). Максимальная конфигурация включает 64 узла в кластере, а минимально необходимо только 2 узла, чтобы обеспечить отказоустойчивость. Решение не ограничивается простым кластером - за счет синхронной репликации на расстояниях до 100м обеспечивается катастрофоустойчивость в распределенном кластере. При правильной организации, полный сбой на одной из площадок не приведет к остановке всей инфраструктуры. Кроме того, поддерживается и асинхронная репликация - все это позволяет строить полноценные катастрофоустойчивые решения.
DataCore Random Write Accelerator позволяет существенно ускорить операции записи за счет использования быстрых SSD дисков, а многоуровневое хранение (multi-tiering) повысит не только скорость работы, но и эффективность использования дискового пространства.
Отличительной особенностью данного решения является то, что заказчик не ограничен в использовании лишь встроенных дисковых ресурсов (и DAS полок). SANsymphony это, по сути своей, еще и виртуализоватор СХД, поэтому в систему можно подключать как имеющиеся, так и новые системы хранения. Не секрет, что в SDS довольно низкая утилизация дискового пространства - в силу изолированности узлов требуется, как минимум, две копии данных плюс дополнительные резервы на снапшоты и пр. Использование внешних СХД может увеличить утилизацию дискового пространства, при этом, управление ресурсами будет по-прежнему сосредоточено в одном месте.
Единственное, что меня всегда немного “напрягало” в SANsymphony это то, что он работает в Windows среде, но, с другой стороны, StarWind тоже работает и ничего :)
Учитывая, что сейчас Huawei может предложить практически любое оборудование, начиная от серверов и СХД, заканчивая инженерными системами в ЦОД, данное решение позволяет получить законченную конвергентную систему от одного вендора, которая отлично масштабируется и сможет закрыть практически все требования. А уж если вспомнить про текущую политическую ситуацию, такое решение от азиатского вендора может оказаться весьма и весьма интересным как для "станционных" компаний, так и для тех, кто опасается возможных ограничений.
Совсем недавно были анонсированы новые системы хранения All Flash Array от IBM - FlashSystem 900 и V9000. Странно, но, как я уже писал, линейка FlashSystem не попала в “программу переименования за миллиард”, хотя интегрированная система FlashSystem V9000 вот уж точно должна была бы стать частью портфеля Spectrum.
В основе архитектуры IBM FlashSystem лежит идея о минимизации задержек на всем пути от внешнего интерфейса до чипа flash-памяти, на котором непосредственно и хранятся данные. Именно это позволяет получить очень хорошие результаты по производительности. Важно отметить, что когда мы говорим о производительности AllFlash систем, оценивать нужно не количество IOPs - их набрать не так уж и сложно, а в первую очередь о как можно низкой задержке (latency). Хорошим результатом можно считать результат меньше 1мс, но борьба уже идет за 500мкс и ниже.
В то время как многие другие производители активно используют стандартные процессоры в “ядре” своих СХД, IBM для FlashSystem продолжает выдерживать “железный” подход ("hardware only datapath”), когда вместо программного кода (пусть даже на разновидности real time OS) активно используются FPGA и кастомизированные компоненты.
Примечательно, что в системе используются не стандартные SSD диски, а специальные модули (MicroLatency Modules), это позволяет избежать “лишних” интерфейсов, а следовательно и лишних задержек. В 900й серии использование таких модулей позволяет обеспечить латентность 90мкс на запись и 155мкс на чтение. При этом объем одного такого модуля может достигать 5.7ТБ В прошлой серии (840) использовались eMLC (enterprise multi-level cell) чипы, в новой же системе перешли на использование более дешевых, но усовершенствованных MLC чипов от Micron (IBM Enhanced MLC). Смешно, но здесь машина IBM по созданию акронимов нашла на камень - не так уж просто будет объяснить клиентам чем eMLC отличается от E-MLC, поэтому наверное решили “Enhanced” в названии оставить без сокращений. :)
Хотя FlashSystem 900 и имеет фиксированную конфигурацию (только один модуль), но обладает необходимыми возможностями, для того, чтобы использовать систему для tier-1 приложений:
обновление микрокода без остановки (не требуется даже снижать нагрузку)
возможность заменить на ходу любой из компонентов системы
избыточность всех компонентов
шифрование данных (AES-XTS 256) без потери производительности
Полезная емкость системы варьируется в зависимости от объема и количества используемых MicroLatency модулей. Минимальный полезный объем - 2.4ТБ, а максимальный - 57ТБ. Важно помнить, что смешивать модули разного объема в одной системе нельзя, поэтому стоит аккуратнее просчитывать необходимые перспективы расширения.
Для подключения СХД к серверам можно использовать различные интерфейсы:
Fibre Channel (FC) - 8*16Gbit или 16*8Gbit
Fibre Channel over Ethernet (FCoE) - 16*10Gbit
iSCSI - 16*10Gbit
Infiniband - 8*40Gbit (QDR)
Все интерфейсные карты в системе должны быть одинаковыми и “смешивать” протоколы в рамках одной системы нельзя.
Декларируется, что FlashSystem 900 может обеспечить до 1.1 миллиона случайных операций чтения 4КБ блоков и до 10ГБ/сек поток на чтение данных. Для операций записи (100% random) - 600.000 IOPs и 4.5ГБ/сек.
Результатом гонки за минимизацией задержек стало полное отсутствие таких привычных для систем энтерпрайз-класса "фишек" как мгновенные снимки, репликация, компрессия, thin provisioning. Если какие-то из этих возможностей действительно необходимы, то у заказчика есть два пути: подключить FlashSystem 900 к своей системе виртуализации СХД (это может быть например SVC или V7000), либо приобрести уже интегрированную систему FlashSystem V9000.
По сути это своего рода гибрид из IBM SVC и FlashSystem 900, но это именно гибрид, а не просто две системы объединенные общей фронтальной заглушкой, как могло бы показаться с первого взгляда. Если мы подключаем FlashSystem к SVC, то мы должны управлять двумя системами, в то время как для V9000 мы имеем единую систему управления.
Во-первых V9000 позволяет расширяться как “вертикально” - добавив до 4х storage enclosures (до 57ТБ каждый), так и “горизонтально” - доведя количество контроллеров V9000 с двух до восьми (4 системы V9000 в кластере). Такое расширение позволит получить до 456ТБ полезного пространства исключительно на Flash. А если учесть возможности RealTime Compression, то мы получим уже 2.2ПБ полезной емкости. И это всего в 34U - достаточно одного(!) серверного шкафа, чтобы вместить весь этот ураган производительности и обеспечить такой объем. Но и это еще не все - можно использовать V9000 и как обычный виртуализатор СХД - все-таки это и SVC тоже, а значит можно к нему подключить имеющиеся системы и использовать на них такие возможности как thin provisioning, снапшоты и многие другие.
Кроме того, поддерживается репликация между V9000 и системами SVC, V7000 - можно строить катастрофоустойчивые решения на базе AllFlash системы IBM. По понятным причинам (полку с Flash модулями нельзя поделить между площадками) не поддерживается конфигурация распределенного кластера (streched cluster).
Конечно, программная “прослойка” между FlashSystem и серверами не обходится даром, поэтому мы вынуждены заплатить латентностью, но плата эта не так уж велика - мы все равно получаем 200мкс на чтение, а это действительно очень мало. Кроме того, за счет использования "горизонтального” масштабирования мы можем получить до 2.5 миллионов IOPs и поток до 19.2ГБ/сек (блоками по 128КБ). А за счет поддержки QoS в V9000 можно гарантировать приложениям требуемый уровень производительности дисковой системы.
Таким образом, FlashSystem 900 нацелена на тех заказчиков, которым нужна экстремально высокая производительность и они готовы пожертвовать программным функционалом систем enterprise-уровня (но хотят сохранить enterprise уровень отказоустойчивости и управляемости). Интегрированная система FlashSystem V9000 ориентирована на заказчиков, которым требуется не только производительность, но и возможность расширить систему, получить богатый программный функционал и возможность защитить данные с помощью репликации. Кроме того, V9000 может быть интересна тем, кто еще не имеет enterprise СХД в своем ЦОД, рассматривает возможности консолидации своих дисковых систем за счет виртуализации.
С нетерпением жду результатов SPC - IBM любит эти тесты. Как раз недавно неожиданно отметились HDS со своей системой VSP G1000, показав отличный результат в 2М IOPs при цене 1$ за IOPs. Вот только чтобы достигнуть цену в 1$ за IOPs пришлось дать почти 60% скидку на железо, зато теперь в лидерах рейтинга.
В IBM заявили,
что готовы в ближайшие 5 лет вложить миллиард $ на разработку Software
Defined Storage нового поколения. Инвестиции будут направлены на R&D в области облачных и объектных систем хранения, а также интеграцию с открытыми технологиями (OpenStack).
Если уже представители IBM заявляют, что "traditional storage is inefficient in today’s world",
наверное действительно пришла пора перемен. Пока, уж не знаю зачем,
решили переименовать все (почти все) системы хранения. Конечно, теперь все поймут, какая IBM супер-современная компания! :)
Встречайте - IBM Spectrum. На сегодняшний день это единственное изменение, которое случилось с IBM System Storage по случаю смены парадигмы.
Хотя,
я все-таки немного сгустил краски - в IBM решили наконец
превратить XIV в программную платформу. Если бы этот шаг был сделан
через год после выпуска Gen3, вот это был бы настоящий взрыв! А сейчас
этим уже почти никого не удивишь, тем не менее, вот он - Spectrum Accelerate.
Остальные "новинки":
Spectrum Virtualize = San Volume Controller (SVC)
Spectrum Scale = General Parallel File System (GPFS)
Spectrum Archive = Linear Tape File System (LTFS)
Spectrum Control = Storage Insights
Spectrum Protect = Tivoli Storage Manager
Нового
названия не нашлось для старичка DS8000, хотя он самый что ни на есть
Software Defined Storage еще с незапамятных времен. Также почему-то в
стороне остались All Flash массивы (Flash System).
За
программной реализацией XIV, на мой взгляд, есть реальная сила, но
будет ли этого достаточно, чтобы вытянуть весь Spectrum на новый уровень
- большой вопрос.
"Железный" состав довольно стандартный - 4 вычислительных узла, каждый содержит:
2 процессора Intel® E5-2620 v2 six-core
192 GB памяти
1 диск SAS 300 GB 10k для загрузки ESXi
3 дика SAS 1.2 TB 10k (для построения VSAN)
1 диск 400 GB MLC SSD (кэш для VSAN)
2 порта 10GbE (под медь или SFP+)
1 порт IPMI под удалённое управление
В некоторой перспективе (второй квартал 2015) заказчикам обещают поддержку HP OneView для централизованного управления инфраструктурой, но пока её нет.
Признаться честно, сверх сухих цифр, сказать мне про данную систему практически нечего: никаких экстраординарных возможностей, никакого дополнительного функционала. Со всех точек зрения - говорим ли мы о железной начинке или о программной части, это только следование "reference" дизайну от VMware. Найти хотя бы какие-то отличия от, например, Supermicro EVO:RAIL я не смог, как не старался. Да, конечно, локальная поддержка в России от "большого" бренда - это серьезный плюс HP. Уверен, однако, что многие из локальных сборщиков/партнеров Supermicro готовы предложить схожие условия по поддержке за сравнимые, если не за меньшие деньги.
Похоже, что для HP это скорее политическое, чем техническое решение - "Да, мы тоже умеем EVO:RAIL и нашим заказчикам не стоит смотреть на других вендоров." С другой стороны, у HP есть система 200-HC StoreVirtual, которую им, скорее всего, продавать заказчикам гораздо интереснее, чем EVO.
Кто же будет покупателем данного решения? Наверное те заказчики, у которых HP является корпоративным стандартом и для которых EVO подходит (а это всё-таки довольно нишевое решение).
На днях EMC анонсировала свой EVO:RAIL appliance - VSPEX BLUE, присоединившись, тем самым, к не слишком многочисленной компании, в которой готовых отгружать решение еще меньше.
Для крупных игроков на рынке довольно сложно продвигать свою реализацию EVO:RAIL. Им нужно заработать, а в случае с EVO, мы имеем жесткие лимиты по дизайну системы, определенный софт и, собственно, практически всё. Поэтому основная задача - показать ценность своего решения, чтобы клиенту не казалось, что цена идет только за брэнд EMC, когда он сравнивает VSPEX BLUE с практически точно такой же (по железным характеристикам) системой от Supermicro (например).
В EMC это прекрасно понимали и на разработку решения потратили довольно много времени и приложили максимум усилий, чтобы потенциальный клиент понимал, что не зря тратит свой бюджет.
Что касается аппаратной части, то здесь всё довольно стандартно - можно выбрать между двумя моделями - 128ГБ памяти на узел, либо 192ГБ. Других отличий нет - 2 процессора Intel Xeon E5-2620 V2, 3*1.2TB SAS, 400GB SSD, 2*10G ethernet. Всё, что потребуется клиенту для запуска - стойка, коммутатор (10Гбит), электропитание и ноутбук для настройки. EMC обещает, что за 15 минут можно вполне уложиться с первоначальной инициализацией системы и уже приступать к созданию виртуальных машин. Настройка, по большей части, происходит автоматизировано и от администратора требуется минимум участия.
Так что отличия решения от конкурентов это конечно не железо, а программные “фишки”.
Первая отличительная особенность, которая сразу бросается в глаза - существенно расширенная система управления (Blue Manager). Она позволяет администратору “видеть”, что происходит с железом на более низком уровне, чем стандартный vCenter. В нее встроены ссылки на дополнительный, предназначенный для VSPEX BLUE, софт от EMC (о нем чуть ниже). Присутствует и доступ к ресурсам технической поддержки, все сервисы, как это теперь модно, "в одном окне".
Раз речь зашла о поддержке, то мы помним, что ранее VSPEX был лишь референсным дизайном для партнёров и именно они должны были обеспечивать первый уровень поддержки. Напротив, VSPEX BLUE это система, которая поддерживается EMC “от и до”. Более того, система ESRS (EMC Secure Remote Services) сама периодически отправляет информацию о состоянии оборудования в службу поддержки (если конечно есть доступ в интернет), поэтому, если не очень внимательно относиться в средствам мониторинга, вы сможете получить сигнал от службы поддержки ещё даже до того, как узнаете о потенциальных проблемах. Проактивный удалённый мониторинг всегда является большим плюсом для заказчика,так как позволяет отчасти переложить ответственность на плечи вендора. Поддержка уровня Premium, помимо времени реагирования 24*7*4 на критичные проблемы, включает в себя еще и установку апдейтов на систему, так что про обслуживание можно практически забыть и заниматься только развертыванием нужных сервисов (и управлением ими).
Защита от сбоя в рамках кластера это прекрасно, но для компаний, использующих более одной площадки для размещения своей ИТ-инфраструктуры, довольно часто бывает востребован такой функционал как репликация данных для обеспечения отказоустойчивости. Поэтому в поставку уже включены лицензии на RecoverPoint for Virtual Machines - по 15 лицензий на каждый из физических серверов, т.е. каждый appliance поддерживает репликацию до 60 виртуальных машин. Это полностью программное решение по репликации и не требует никакого дополнительного оборудования. Но даже если у вас нет удаленной площадки, никто не мешает использовать локальные реплики для быстрого восстановления в случае сбоя (это совсем не то, что снапшоты внутри VMware). Мы можем сами указать требования по RPO для наших виртуальных машин и обеспечить уровень доступности сервисов, соответствующий бизнес-задачам.
Ещё одной особенностью системы является система резервного копирования VDPA (а не только VDP, входящая в состав лицензии на Enterprise Plus) с коннектором для Data Domain. Ведь нельзя же делать резервную копию данных на сам VSPEX BLUE. :) Вся необходимая программная часть уже включена в поставку VSPEX BLUE (конечно, кроме самого Data Domain). Поддержка дедупликация и высокой скорости disk-to-disk резервного копирования позволяют оптимизировать схему бэкапа и минимизировать его влияние на продуктивную среду. Одна из "младших" систем Data Domain станет отличным дополнением к проекту по внедрению.
Меня всегда настораживал ограниченный объем дискового пространства, который характерен для систем EVO:RAIL - в случае с EMC это по 3 диска 1.2TB SAS плюс 400GB SSD для VSAN Cache на каждый узел. Это даёт примерно 12ТБ на систему, но ведь полезная емкость будет ещё минимум в 2 раза меньше. Конечно, 6ТБ это не так мало, но, по современным меркам, совсем не так уж и много. Поэтому ещё одна “фишка” системы нацелена как раз на тех, кому нужен объем, но нет желания ставить свою собственную дополнительную дисковую систему (либо из-за невысоких требований к производительности, либо из-за того, что обращение к данным не такое уж и частое). Каждый покупатель VSPEX Blue получает возможность подключить до 10ТБ данных из “облака” (Amazon, Google и др.) к EMC Cloud Array VE. Поддерживается до 1ТБ локального кэша, который обеспечивает высокую производительность при работе с “облачными” данными. В облаке можно размещать как данные, так и непосредственно образы виртуальных машин (работающих!).
И, да, для тех кому мало одной системы - можно поставить до 4х VSPEX BLUE в один кластер (16 физических хостов).
Получилась довольно интересная система, тем более, что на таком массовом рынке серверов EMC никогда не играла. Посмотрим, насколько быстро получится "отхватить" долю. Весьма успешный и совсем недавний пример Cisco подтверждает, что можно и с места высоко прыгнуть.
Как обычно, громко и шумно EMC анонсировали новую high-end дисковую систему. На смену VMAX и VMAXe пришли аж целых три системы - VMAX 10K, 20K и 40K. Правда, здесь есть и небольшой подвох - 10K и 20K вроде как никуда и не пришли. А не пришли они из-за того, что никуда и не уходили - это уже хорошо знакомые нам VMAXe и VMAX, только с новыми названиями. Действительно, в прошлый раз маркетологи в EMC явно перемудрили и назвали все модели новыми именами (VMAX, VPLEX, VNX...), но никто не побеспокоился о том, что же делать, если потребуется все-таки их немного усовершенствовать - процессоров там добавить, либо еще что-нибудь прикрутить. Вот и пришлось теперь менять название. Что касается новой “звезды” в лице VMAX 40K, то из “железных” изменений все довольно ожидаемо - более современные шестиядерные процессоры (2.8ГГц Westmere), больше кэш памяти плюс шина PCI express 2.0:
За счет этого добились (по заявлениям) двукратного роста производительности в бэкенде и на линейных нагрузках “снаружи”. Что касается OLTP нагрузки, то здесь декларируется примерно 25% роста. Без изменений осталось максимальное поддерживаемое количество дисков 3.5” (2400), но зато можно использовать до 3200 дисков форм-фактора 2.5” (причем их можно установить до 400шт в стойку). Как и прежде, используется FC бэкенд и FС диски. Кроме EMC и HP (3PAR) в системах high-end c FC дисками никого не осталось - IBM и Hitachi уже давно перешли на SAS. Существенное ограничение - нельзя смешивать в одной системе диски 2.5” и 3.5” (не только в одном шкафу, но и вообще во всей системе). Нельзя и проапгрейдить 10K до 20K, а 20K до 40K, так что, несмотря на схожесть названий, эти системы разделены жестким барьером и пользователь не имеет возможности вспрыгнуть на подножку стремительно уходящего поезда прогресса, зацепившись за “младшую” систему. Хотите перспективы - берите сразу 40K.
Видимо в EMC получили ряд нареканий о том, что затруднительно бывает разместить монстра VMAX в ЦОД из-за нехватки площадей, поэтому сейчас можно “разбросать” части VMAX 40K (опять же, только 40K!) по ЦОД (в пределах 25м).
Если с точки зрения железа все, как я и написал, ожидаемо и логично, то в софте добавилось возможностей несколько больше. Самое заметное - Federated Tiered Storage (FTS). Говоря простыми и понятными словами, это виртуализация внешних (сторонних) СХД. “Сторонних” звучит, правда, несколько натянуто - на первом этапе поддерживаются только Symmetrix DMX-4, DMX-3, DMX, CLARiiON CX4 / CX3, VNX и (вот же она, “сторонняя система”!) Hitachi USP-V. Список конечно весьма и весьма скромен, да и виртуализация динозавра в лице DMX3 (а и USP-V тоже) выглядит довольно - нужно дважды заплатить за лицензии на емкость - сначала за емкость самого DMX3, а потом за нее же, но уже в ценах для VMAX. Однако хочется надеяться, что список протестированных и поддерживаемых устройств будет расти. Виртуализованная емкость может использоваться со всеми замечательными функциями (FAST VP, TimeFinder, SRDF, VLUN). В этом плане VMAX выглядит, на мой взгляд, даже немного интереснее, чем VPLEX. С другой стороны, получается соревнование по функционалу между двумя “топовыми” продуктами одного производителя. Уж лучше бы сделали “VMAXPLEX”, который бы обладал преимуществами обеих систем! Из приятного - Federated Tiered Storage доступен не только на VMAX 40K, но и на 20K (напомню, что это нынешний VMAX).
Для FAST VP появилась возможность интеграции с SRDF и теперь на удаленной площадке система в курсе о том какие блоки должны лежать на быстрых дисках, а какие - нет. Теперь при переходе на резервную площадку можно надеяться на сопоставимую производительность (если конечно системы на площадках идентичны).
Перевод всех бородатых администраторов на простой и понятный GUI продолжается, поэтому теперь можно управлять VMAX из красивого Unisphere (правда, с приставкой “for VMAX”).
Программные улучшения коснулись в том числе и интеграции VMAX с RecoverPoint (поддержка сплиттера на уровне СХД).
Получилась ли принципиально новая система? Не уверен – подавляющее число новшеств это либо результат планового развития архитектуры x86, либо усовершенствования очередного релиза Enginuity. Остается открытым и вопрос узких мест – апгрейд узлов и увеличение дисков в бэкенде на 33% привели лишь к 25% росту производительности (OLTP). А как на производительность будет влиять FTS? Подрастет ли производительность за счет кэша VMAX или, напротив, подрастет только латентность? Если FTS позволяет использовать возможности VMAX на системах класса ниже, то смогут ли разработчики перенести эти возможности в VPLEX (ах, как этого недостает!)?
Как обычно, много вопросов на которые мы сможем найти ответы лишь по прошествии некоторого времени и (ведь такое хотя и маловероятно, но тоже может случиться!) каких-то публичных тестов. Но это я уже совсем размечтался наверное!
Анонсирована долгожданная поддержка процессоров AMD Opteron в системе виртуализации ScaleMP vSMP, про которую я уже писал. До настоящего момента необходимо было использовать только процессоры Intel Xeon серий 5xxx/6xxx или 7xxx.
Поддерживаться будут как процессоры серии Opteron 6100, так и будущие “Interlagos”. Можно будет объединить до 512ти процессоров в единую виртуальную машину с объемом памяти до 64ТБ. Уже с октября этого года релиз vSMP Foundation будет доступен для ограниченного круга заказчиков, а с 21 ноября строить vSMP кластер с использованием процессоров AMD Opteron смогут уже все желающие.
Вчера вышел первый апдейт к версии 4.1 ESX/ESXi и vCenter Server. Ключевых изменений практически нет – в основном исправления ошибок и поддержка новых операционных систем Windows7 SP1 и Windows Server 2008R2 SP1, а также RHEL 5.5 и 6.0. Для vCenter теперь есть поддержка MS SQL 2008R2 и IBM DB2 9.7.2 (как бесплатной Express C, так и Enterprise). ESX/ESXi теперь умеют поддерживать до 160 логических процессоров.
Более подробная информация о релизе на сайте VMware:
Вчера случилось то, чего все уже давно ждали. Как мы все знаем, SAS диски крепко обосновались в системах хранения начального и среднего класса, но оставался последний оплот дисков с интерфейсом Fibre Channel – системы Hi-End. Но вчера и этот бастион пал – HDS анонсировали новый флагман Hi-End класса VSP (Virtual Storage Platform). И конечно же, смена интерфейса бэкэнда вовсе не является основной особенностью новой системы. Сменилось многое. Да по большому счету, можно сказать что сменилось практически всё (ну разве что кроме преемственности функционала). Попробую хотя бы частично пробежаться по списку:
(сразу бросается в глаза) шкаф стал стандартным (19’’), хотя конечно в “свой” шкаф систему не поставить
Дисков стало больше (до 2048шт). В ряд можно поставить 6 шкафов, в 2х из них контроллерный модуль займет 14U и еще 26 юнитов останется под диски, а 4 шкафа – только для дисков. 2048 дисков можно поставить только с использованием 2.5’’ SFF дисков (да-да, поддерживаются и такие!). Если используются 3.5’’ диски, то максимальная набивка уже только 1280 дисков.
Теперь можнонужно использовать однофазное питание (на USP-V и более ранних требовалось 3 фазы)
Поддержка до 96 портов FCoE (правда немного позднее), а заодно отказались от поддержки ESCON интерфейса (кто-то его еще использует?).
Максимальный объем кэша увеличен до 1ТБ(!)
Защита кэша посредством записи на флэшку, а значит уже не требуется такое огромное количество батарей, которое было привычным всем владельцам монолитных систем.
Появилась нормальная поддержка SSD дисков (см. следующий пункт).
Вместе с SSD появилась и технология автоматической миграции данных между уровнями хранения (Page Level Tiering).
Анонсирована поддержка инициатив VMware в области хранения (VAAI).
Поддержка VMotion Anyware посредством Hitachi Dinamic Link Manager.
Поддержка шифрования на уровне BED (XTS-AES 256).
Уверен, что забыл еще про что-нибудь упомянуть. Но даже этот список показывает, что работа была проделана большая.
Основные изменения коснулись архитектуры системы, которая является уже пятым поколением. Из каких же частей состоит система?
VSP может состоять либо из одного контроллерного шасси (не контроллера, а именно шасси), либо из двух (в разных шкафах).
Шасси соединяются по PCI-E (правда первого поколения) шине и образуют единый комплекс. Все компоненты внутри одного шасси также связаны через PCI-E. Связь обеспечивается посредством Grid Switch, коих может быть либо 2, либо 4 на одно шасси. “Мозгом” являются модули VSD (Virtual Storage Director) – именно они занимаются всей работой с томами, обеспечивают thin provisioning, tiering и т.д. В отличие от конкурентных решений, не требуется обеспечивать высокоскоростной линк между VSD – каждый том в данный момент времени может управляться только одним VSD. Уже никого не удивить наличием процессоров x86 внутри системы. И VSP не является исключением – выполнение задач общего назначения отданы именно процессорам Intel (quad core Xeon). Диски подключаются к BackEnd Director (BED), на каждом из которых по два порта 4lane SAS 6Gbit. Т.е. в максимальной набивке можно получить до 64х линков 6Gbit SAS (48GB/sec). Причем приобретать систему вместе с дисками (и соответственно BED модулями) вовсе не обязательно (ведь все помнят, что уже USP-V умеет виртуализировать внешние системы хранения) – можно использовать и имеющиеся СХД, подключая их через VSP. Хосты подключаются к модулям FrontEnd Director (FED), каждый из которых поддерживает до 12ти портов 8Gbit FC (или FICON). Позднее должны появиться 4х портовые FED модули FCoE. Вот здесь уже стандартными процессорами не обошлись и на помощь пришли специализированные двуядерные процессоры собственного производства Hitachi (data accelerator ASIC). Именно они занимаются непосредственной обработкой критических к латентности данных. Последним в списке значатся Data Cache Directors – модули с кэш памятью (до 4шт в шасси), каждый может иметь объем от 32 до 128ГБ. На каждом из модулей расположен flash SSD для хранения кэша при отключении питания. Кэш записи зеркалируется попарно между двумя модулями (прочитанные же блоки всегда кэшируются только в одном экземпляре). Еще одна особенность в организации памяти заключается в том как защищена служебная память в VSD модулях. Она уже не зеркалируется между директорами, как в прежних системах, но зато резервная копия всегда сохраняется в паре кэш модулей (это не зеркалирование, а именно резервная копия, оптимизированная для быстрого восстановления). А так как память в кэш модулях, в свою очередь, уже зеркалируется между ними, то получается троекратная защита служебных данных- бэкап на паре Cache Director + хранение на flash памяти (как и любая другая записываемая в кэш информация). Такой подход позволяет еще больше “развязать” VSD модули друг от друга. Физически в контроллерном шасси все модули, к которым могут подключаться кабели, выведены на заднюю сторону шкафа:
А с фронта можно получить доступ к VSD и кэш-модулям:
Еще несколько слов про возможности динамической балансировки между уровнями хранения. Как и в случае thin provisioning, все операции по миграции делаются блоками в 42МБ. На мой взгляд – многовато. Уровни хранения можно выбирать любые – SSD/SAS/SATA или SAS/SATA или SSD/SATA. Но новые данные всегда сначала попадают на самый “быстрый” уровень хранения и, уже если они больше нужны, то постепенно сдвигаются на “медленный” уровень. В первом релизе page level tiering нет поддержки RADI10, также не поддерживаются внешние системы хранения – можно использовать только внутренние диски. Ну и поддержки mainframe тоже нет (планируется позднее).
Ко всем этим замечательным возможностям добавляется еще переписанная система управления, которая стала заметно симпатичнее и функциональнее. Контроль доступа на базе ролей (RBAC) также поможет упростить жизнь при администрировании VSP.
Ну и справедливости ради, стоит заметить что HP (как OEM партнер HDS) также анонсировали систему StorageWorks P9500. Говорят, что принимали непосредственное участие в разработке. Как видно, постепенно названия продуктов сводятся к единой базе – уже есть P2000 и P4000, теперь P9500. И остался еще изрядный промежуток для продуктов 3PAR (поглощение на днях как раз завершилось).
Попытки сделать стандартный тест (бенчмарк) для систем виртуализации делались уже давно, но единого общего знаменателя я не встречал. VMware использует свои попугаи, остальные стараются как-то выкручиваться. Плюс были попытки создать независимые бенчмарки, но как-то пока никто не прижился.
Но вот 14 июля сего года небезызвестный SPEC запустил свой бенчмарк для виртуализации - SPECvirt_sc2010. Основан он на целом ряде других тестах SPEC – SPECweb2005, SPECjAppserver2004, SPECmail2008. В виртуальной среде создается “инфраструктура” из нескольких VM, в которых и выполняется набор тестов:
Таких “инфраструктур” (Tile) на одном сервере может быть запущено несколько и как раз это показывает насколько хороша масштабируемость:
Результаты бенчмарка отображаются в виде <Overall_Score> @ <6*Number_of_Tiles> (т.е. после символа @ идет суммарное число VM, запущенных на хосте).
Подробнее про схему бенчмарка можно прочитать здесь.
Хочется верить, что выход в свет SPECvirt_sc2010 позволит немного более предметно проводить сравнения и гипервизоров, и железа.
На текущий момент в тестах наметился уверенный лидер – IBM с сервером x3650M3 и KVM в качестве гипервизора (результат 1169 @ 72). Во многом правда это лидерство обеспечено тем, что на сегодня это и единственный опубликованный результат :)
История придуманная и любые совпадения с реальными персонажами являются случайными (хотя и вполне вероятными).
Жил да был системный администратор, работал себе в небольшой компании, серверов у него в услужении было всего ничего – ну пусть будет 4 штуки, скажем. На серверах все стандартно, везде Windows Server установлен да и приложения на нем всякие работают – и контроллер домена, и файловый сервер, и почта, и SQL тоже был.
Жил бы наш админ, да и горя бы не знал, только как случись какая неполадка в его хозяйстве, так сразу его под белы рученьки на ковер к начальству ведут и ругают на чем свет стоит. А он, бедный, только руками разводит да слезно просит бюджет увеличить, чтобы большую СХД купить – без нее никак у него не получится все задачи в виртуальную инфраструктуру перевести, обеспечив тем самым большую отказоустойчивость. Начальство же ему в ответ, хмуря брови - “Нет! Тебе лишь бы деньги казенные в расход пустить! Мы вон тебе серверов купили отличных уже недавно! А нагрузка, сам говоришь, процентов 10 от силы. Да как у тебя язык-то поворачивается о таком просить?! Кризис же на дворе! Поди прочь, с глаз долой и сделай срочно, чтобы все работало!”.
И после таких разговоров шел обычно админ, понурив голову, к себе в кабинет и думку думал, но решение никак не приходило. Он уже и прикинул, какая производительность для текущих задач нужна – действительно, если Hyper-V использовать, то и пары физических серверов хватит. Но все равно – нужен внешний сторадж, чтобы хранить данные виртуальных машин. Можно конечно на “лишнем” сервере сделать iSCSI target (благо вариантов таких полно сейчас, даже и бесплатных). Но что будет, если это сервер “рухнет”?! Тогда уж сразу можно заявление на стол, а голову в петлю. Резервные копии на второй сервер немного подсластят жизнь, да только остановка сервисов при сбое все равно будет слишком долгая. Как же быть?
И вдруг вспомнил админ, что совсем недавно читал в каком-то блоге :) про Sanbolic Melio 2010. Есть же там и специальная редакция для Hyper-V, цена которой начальство ну никак не расстроит! И поддержка iSCSI есть, и кластерная файловая система все проблемы с CSV томами снимет. Так может быть можно и два iSCSI хранилища в “зеркало” объединить, чтобы защититься от сбоев? А ведь и правда можно (в DataCenter версии Melio Suite)! Тут уж и работа закипела, освободил админ два сервера, настроил на внутренних дисках RAIDы, установил iSCSI target, настроил все. Поставил на серверы с Hyper-V Sanbolic Melio 2010 (покупать сразу не решился, поэтому получил сначала демо-версию, которая по функционалу от оплачиваемой и не отличается ничем, кроме ограничения на срок использования). Создал зеркало, отформатировал диски – и все!
После этого сбой любого из серверов Hyper-V приводил только к перезапуску виртуальных машин на “живом” сервере, а если использовать DataCenter редакцию Melio, то и сбой сервера iSCSI вообще никак на доступности сервисов не отражается – вторая половина зеркала берет всю нагрузку на себя.
И вот тут-то админ и понял, что значит завоевать уважение и благосклонность начальства – бюджет решения был минимизирован, имеющееся оборудование было полностью задействовано, отказоустойчивость повысилась многократно. Теперь можно и в отпуск отпроситься, не опасаясь что через два дня срочно вызовут, да и обругают за то что ничего не работает.
Вот такая вот сказка получилась. Правдивая? По моему мнению - более чем!
Задача объединения нескольких серверов в один гораздо более мощный замечательно решается при помощи vSMP Foundation от компании ScaleMP – про это я некоторое время назад уже писал. Если вкратце, то используя стандартные x86 серверы, infiniband и гипервизор от ScaleMP можно получить сервер поддерживающий до 32х сокетов и до 4ТБ памяти. Интересно, что конфигурации машин, входящих в кластер могут отличаться – если процессорных ресурсов нужно не слишком много, то часть машин может быть с “быстрыми” процессорами, а остальные с минимальными возможными и предоставлять в качестве общего ресурса только оперативную память. Однако у vSMP Foundation есть и некоторые особенности, про которые необходимо помнить. Во-первых, установить на такой сервер можно далеко не всякую операционную систему – на текущий момент это может быть только Linux, причем для оптимальной производительности нужно либо пересобрать ядро, либо использовать вариант от ScaleMP (они есть в частности для RedHat). Во-вторых, vSMP предназначен именно для объединения ресурсов. То есть вместо двух (трех, четырех…) серверов мы получаем один, но более мощный, соответственно, выход из строя одной из машин вызовет остановку/перезагрузку всего комплекса. Кроме того, так как речь идет про объединение, то на один комплекс vSMP нельзя поставить несколько операционных систем (т.е. выделить полторы машины для одной задачи, а еще две с половиной для другой). Но последний пункт был верен только до недавнего момента! Буквально на днях была анонсирована технология VM-on-VM. Что это такое? Очень просто - фактически заявлено о начале поддержки виртуализации серверов на базе KVM и Xen в кластере vSMP Foundation. Это дает возможность существенно снизить цену “железной составляющей” на базе 4-8ми сокетных систем. А это, в свою очередь, позволит консолидировать (виртуализовать) более требовательные к ресурсам сервисы без использования дорогостоящего оборудования. Декларируется также упрощение управления, впрочем, здесь я не испытываю особенного энтузиазма – самим vSPM тоже нужно управлять, поэтому снижение затрат на управление будет не самым важным аргументом. По крайней мере не таким важным, как цена решения.
Но приятные новости этим не ограничиваются – параллельно была анонсирована и версия 3.0 vSMP Foundation. Основные нововведения касаются поддержки процессоров Nehalem-EX и Westmere-EP. Теперь можно использовать несколько infiniband HCA карт параллельно, причем нагрузка будет равномерно распределяться между ними. Для объединения 4х машин можно обойтись без коммутатора Infiniband – это позволяет существенно снизить начальные вложения. Существенно расширен список поддерживаемых адаптеров – это HBA от LSI и Emulex, кроме того, добавлена поддержка 10Гбит сетевых адаптеров Broadcom. В новой версии увеличены и “максимумы” кластера – теперь можно объединять до 128 серверов, каждый из которых может иметь до 128 процессоров (ядер или потоков); объем поддерживаемой оперативной памяти увеличен до 64ТБ. Версия 3.0 будет доступна заказчикам начиная с 14 июня.
Еще один уверенный шаг EMC в сторону концепции IT as a Service сделан. Под брызги шампанского и бурные овации на EMC World 2010 анонсирован VPLEX. Выбранное имя конечно не удивляет – сейчас продукт, в названии которого не будет буквы “V”, могут представить только аутсайдеры (даже если к виртуализации никакого отношения продукт и не имеет, а здесь-то как раз виртуализация на месте). Прозвучали и громкие слова “Storage federation”. VPLEX преподносится как таблетка от всех проблем, связанных со сложностью администрирования разрозненных “островков” систем хранения. Казалось бы, что нового? Все это уже давно есть и у IBM (SVC), и у HDS (USP-V), и даже у самой EMC (Invista) – системы виртуализации СХД уже не первый год на рынке. Но ключевой особенностью VPLEX является возможность объединять не только СХД, расположенные на одной площадке, но и системы территориально распределенные (в перспективе – на сколь угодно большие расстояния). Можно сказать, что VPLEX это вертикально и горизонтально масштабируемая система виртуализации СХД, позволяющая использовать глобальный (распределенный) кэш. В основу продукта положены технологии приобретенные вместе с компанией Yotta Yotta. Вполне логично, что VPLEX эффектно подается в связке с VMware vMotion как решение, позволяющее беспрепятственно перемещать нагрузку между датацентрами и, тем самым, обеспечивающее максимальную гибкость и подкупающую простоту администрирования. Идея произвольным образом “двигать” сервисы между площадками если смотреть “сверху” конечно импонирует (по крайней мере, до того как надо будет закопаться в детали). Привлекательно выглядит возможность передвигать ресурсоемкие сервисы по часовым поясам в зависимости от стоимости вычислительных ресурсов в данное время суток. Звучит красиво, ничего не скажешь!
Но, как и всегда, есть несколько “но”. В настоящее время VPLEX поставляется только в двух вариантах – VPLEX Local (для работы на одном сайте) и VPLEX Metro (для объединения двух площадок, расстояние между которыми позволяет использовать синхронную репликацию, т.е. до 100км). В первом случае решение ничем не отличается от любой другой системы виртуализации СХД, во втором конечно есть отличия, но и здесь конкурентам есть что предложить. Справедливости ради нужно сказать, что в перспективе EMC обещает еще две версии VPLEX – Global, для объединения двух площадок на расстоянии более 100км (асинхронная репликация) и VPLEX Geo, который уже позволит объединять несколько датацентров на произвольном расстоянии друг от друга. Все это, однако, ждет нас не раньше 2011 года. Кроме того, функционал VPLEX в плане виртуализации также довольно ограничен на текущий момент – поддерживаемые “чужие” СХД (IBM, HDS) можно пересчитать на пальцах одной руки (список конечно планируют еще расширять); нет поддержки ни thin provisioning, ни мгновенных снимков – если это необходимо, то придется пользоваться функционалом СХД. Собственно, из-за этого скорее всего и не было объявлено о смерти Invista. Картина становится несколько мрачнее – в настоящий момент VPLEX для большинства не принесет долгожданной простоты управления, а скорее добавит сложностей. Нужно будет не только научиться управлять VPLEXом, но и продолжать следить за виртуализированными СХД и, возможно, гораздо аккуратнее заниматься выделением пространства, так как теперь между СХД и серверами окажется новое устройство, которое будет усложнять представление данных.
Что же за устройство скрывается за красивым названием VPLEX? Минимальный модуль (VPLEX Engine) состоит из двух кастомизированных x86 серверов (каждый отдельно называется Director), упакованных в одно шасси высотой 4U. Каждый director оснащен двумя 4х ядерными процессорами, 32ГБ памяти и имеет 16 дисков и 16 хостовых портов FibreChannel 8Gbit. Разумеется в комплекте обязательным образом идет еще и SPS (ИБП). Максимум в кластер для увеличения производительности можно объединить до 4х Engine (получается 8 директоров). Друг с другом директоры общаются через выделенные FC порты (помимо упомянутых выше 32х штук), для чего используются отдельные коммутаторы. На каждом директоре присутствует по 2 порта для взаимодействия внутри кластера и 2 порта для взаимодействия с удаленными комплексами. В максимальной набивке комплекс VPLEX выглядит примерно как на картинке справа. Помимо 4х узлов и двух коммутаторов в стойке также размещается управляющий сервер, через который собственно и происходит вся работа с VPLEX. Из 32ГБ памяти каждого директора, в качестве кэша используется около 20ГБ, таким образом, на каждой площадке можно получить до 160ГБ кэша. Кэш используется только для чтения: при получении запроса VPLEX проверяет наличие данных у себя в кэше, если данных там нет, то проверяется глобальный кэш (память остальных узлов) и только если данных не оказывается и там, делается запрос на чтение с дисков. Вся запись ведется “сквозным” образом, т.е. подтверждение хосту об успешном завершении отправляется только после того как VPLEX получит соответствующее подтверждение от всех дисковых систем, участвующих в записи блока данных. Так как VPLEX это по сути своей система виртуализации СХД, то выделение LUNов хостам делается через VPLEX (хотя конечно можно и просто “пробрасывать” LUN с дисковой системы без изменения). В общем случае, картина примерно такая: LUNы, созданные на дисковой системе, отдается во владение VPLEXу, на них создается один или несколько экстентов (extent) произвольного размера, затем эти extent объединяются в девайсы (devices), на которых можно уже создать виртуальные тома (virtual volume) и уже эти самые virtual volume можно раздавать хостам. На первый взгляд немного запутано, но практически все системы виртуализации так и работают. Каждый комплекс VPLEX может раздавать хостам до 8000 LUNов.
Итак, анонс прошел, фанфары прозвучали, что в сухом остатке? Отношение неоднозначное. Сказать, что EMC “стрельнули” уникальным продуктом я не могу. Вот если бы все это было реализовано на базе VMAX, это было бы действительно “круто”! Концептуально предложенное решение мне, впрочем, и так нравится. Но вот что не нравится: отсутствие кэша на запись, отсутствие таких функций как thin rpovisioning, снимки, клоны и т.п. Сейчас можно говорить лишь только об озвученном плане на будущее развитие. План радужный, но насколько он будет воплощен в жизнь остается под вопросом. А пока заказчикам остается выслушивать истории про Storage Federation и IT as a Service ну и конечно про Cloud Computing. Впрочем, если вдруг прямо сейчас нужно взять и начать строить (именно начать) пресловутое облако, то возможности VPLEX могут оказаться востребованы. Для двух площадок можно даже обойтись и без VMware SRM, продолжая обеспечивать высокий уровень доступности сервисов. Так что заказчики на VPLEX безусловно найдутся, но сможет ли он серьезно потеснить IBM SVC (или хотя бы HDS) на рынке систем виртуализации – большой вопрос. И на сегодняшний день мой прогноз – в ближайший год шансов очень и очень мало.
9го февраля IBM анонсировал новое лезвие HS22V. Название недвусмысленно намекает на то, что прицелом является виртуализация. Действительно, основное отличие от HS22 (которые уже заняли основную нишу в блейдах IBM), состоит в наличии 18 (а не 12ти) слотов под память. А память является, как известно, наиболее востребованным компонентом при внедрении виртуализации серверов – процессорной мощности зачастую бывает много, а памяти почти всегда не хватает.
Вместо двух hot-swap дисков предлагается использовать пару фиксированных 1.8” 50GB SSD дисков (поддерживается RAID-0 и RAID-1). Желающие могут добавить аппаратный RAID с батарейкой (впрочем, не думаю, что для данного лезвия это будет хоть как-то востребовано). Также уже традиционно присутствует разъем для USB накопителя с предустановленной Vmware ESXi (3.5 или 4). Что касается плат расширения, то здесь все осталось без изменений по сравнению с HS22. Базовые модели лезвий используют процессоры X5570 и E5540, можно также заказывать вариант с процессорами E5506 (но массово он поставляться не будет).
Для виртуализации весьма удобно использовать Virtual Fabric Adapter, про который я уже писал. Для тех, кому актуально использование FibreChannel, но уже есть прицел на FCoE и/или 10Гбит также есть хорошее решение - Virtual Fabric Extension Module.
Начало отгрузок HS22V планируются на 16е марта. Кроме того, в интернет просочилось название нового лезвия на процессорах Nehalem EX - HX5. Предполагается поддержка 4х процессоров на собственном чипсете eX5. Напомню, что текущую серию процессоров Xeon MP в лезвиях IBM не встретить – аргументом было повышенное энергопотребление и тепловыделение. А на Youtube давно уже можно найти совместный рассказ IBM и Intel о готовящемся чипсете и апдейте линейки 3850M2/3950M2.
С завидным постоянством вижу вот такого плана вопрос:
“Мы установили дисковую систему, создали один LUN, все настроили, подключили два сервера. На одном сервере файлы записываем, а на другом никаких изменений не видно. Да еще и ошибки какие-то странные. Что надо еще настраивать?”.
Причем, как это ни странно, технический уровень спрашивающих может быть очень разным, а вопрос один и тот же. А ведь, казалось бы, все очевидно: файловые системы (большинство), которые мы привыкли использовать (NTFS, EXT3, …) просто не умеют работать в таком “распределенном” режиме. Представьте, что на сервер А мы записали на диск файл, но каким образом об этом станет известно серверу B? Без специальной кластерной файловой системы, которая сообщит ему об этом – никак. И наиболее вероятным результатом (даже сравнительно короткого) такого “испытания” на обычной файловой системе будет полный ее крах. Поэтому даже и эксперименты проводить не стоит – работать не будет! А что тогда делать и нужно ли это вообще? В большинстве случаев (особенно если очень пристально посмотреть на задачу или заказчика :) ) такой функционал действительно оказывается ненужным и для совместного доступа к файлам достаточно использовать CIFS (в Windows) или NFS (в Linux). Но, тем не менее, существует и довольно много задач, где общий доступ к дисковому устройству если и не необходим, то очень важен. Как для более простой реализации, так и для лучшей производительности системы. Для того чтобы такой доступ обеспечить нам и нужна будет кластерная файловая система. Существует их довольно много, подавляющее большинство ориентировано на Linux/Unix (RedHat GFS, IBM GPFS, Lustre, HP Plyserve и т.п.), но и Windows не остался в стороне (Sanbolic MelioFS, HP Polyserve, IBM GPFS). Исторически решения под Linux использовались для HPC кластеров (и ряда других приложений), а под Windows в основном для обработки медиа-контента. Сейчас дисбаланс уже не так заметен – Windows работает на всех фронтах. Кроме того, все активнее внедряются системы виртуализации на базе Hyper-V в Windows Server 2008 и 2008 R2. И, если у основного конкурента (VMware) кластерная файловая система уже есть (VMFS), то в случае с Hyper-V нужно либо обходиться без нее, либо использовать сторонние продукты. Но даже и в случае с VMware разделяемая файловая система может очень пригодиться – например при использовании совместно с бесплатным VMware Server можно размещать образы виртуальных машин на общем дисковом ресурсе, что значительно упрощает миграцию и в разы снижает время простоя при сбоях.
Сегодня более подробно я остановлюсь на решениях компании Sanbolic. Помимо кластерной файловой системы MelioFS, в портфель продуктов постепенно добавлялись и другие решения – это и система управления томами LaScala, и SILM, и AppCluster (о них немного ниже), а выбрать что же именно нужно купить, чтобы получить искомый результат, становилось все сложнее. И, если представители интегратора в большинстве случаев хорошо понимают что и для чего нужно, то объяснить клиенту, что ему нужна не одна лицензия за 2000$, но к ней еще нужно докупить две лицензии по 1500$, было в некоторых случаях сложно. В настоящее время ситуация существенно упростилась и предлагается всего 4 лицензии: Melio Virtualization, Melio Professional, Melio Enterprise и Melio Data Center. Благодаря этому выбор оптимального решения стал гораздо проще.
Все четыре продукта включают в себя (помимо кластерной файловой системы) систему управления томами (volume manager) LaScala. Поддержка страйпинга и конкатенации позволяет получить высокопроизводительный том необходимого объема. Также во все бандлы входит система SILM (Simple Information Lifecycle Manager), которая, на основе заданных пользователем политик, может перемещать файлы между различными системами хранения. Например, файлы, к которым не было обращения более 10 дней, будут перенесены на более медленную дисковую систему. Важно отметить, что поддерживается “смешанный” режим работы – данные могут располагаться не только на томах MelioFS, но и на любых других дисках (в том числе и локальных).
Melio Virtualization ориентирован на заказчиков, которые внедряют у себя Hyper-V или VMware Server, и позволяет получить всем серверам доступ к общей дисковой подсистеме (iSCSI или FC) для размещения на ней образов виртуальных машин. Благодаря поддержке технологий Quick и Live Migration, а также отсутствию ограничения на число серверов в кластере, актуальность данного решения фактически прямо пропорциональна числу физических серверов Hyper-V.
Второй, ориентированный на виртуализацию продукт - Melio Professional. Он предназначен для развертывания отказоустойчивого высокопроизводительного кластера системы динамической загрузки образов операционных систем на базе Citrix Provisioning Services. На общей файловой системе хранится как база данных, так и сами vDisk вместе с файлами кэшей записи. Нужно помнить, что данный бандл имеет ограничение на включение максимум двух узлов в кластер (а использовать меньше и смысла не имеет).
Два оставшиеся варианта лицензий уже не являются такими узкоспециализированными и предназначены для широкого круга заказчиков, чьи задачи не ограничиваются только виртуализацией. Melio Enterprise поддерживает совместную работу до 4х узлов в одном кластере и имеет ряд ограничений по сравнению с “топовой” версией Melio Data Center. В частности, нет поддержки зеркалирования (RAID1) и Quality of Service. Обе версии позволяют создавать высокопроизводительные кластеры файловых серверов, в том числе и с поддержкой балансировки нагрузки (NLB). Разумеется поддерживается DFS и ACL. Возможность динамического расширения файловой системы и томов позволяет избежать лишних остановок сервиса для обслуживания системы. По мере роста требований к файловым серверам можно добавлять как серверы, так и системы хранения в существующий кластер, увеличивая тем самым как суммарную емкость, так и производительность системы в целом:
Также в состав обоих пакетов входит AppCluster Manager – средство управления active-active кластерами MS SQL, когда соответствующие базы данных размещены на разделяемой файловой системе. Конечно, это решение не позволяет (в силу архитектуры MS SQL) построить аналог Oracle RAC, но дает возможность обеспечить минимальное время переключения между серверами в кластере в случае сбоя, а также балансировать нагрузку между физическими машинами:В варианте Data Center AppCluster работает совместно с QoS, чтобы позволяя критичным базам иметь приоритет при работе с дисковыми ресурсами.
Для тех же кто использует Hyper-V есть еще зачастую весьма веская причина использования Enterprise или Datacenter версий – технология Pass-through I/O увеличивает производительность дисковой подсистемы так как не требуется оповещение остальных машин в Windows Failover кластере об операциях записи в виртуальных машинах.
Триальную двухнедельную версию можно получить, зарегистрировавшись на сайте Sanbolic. А купить и/или получить более подробную информацию, как обычно, можно у нас. :)
