К уже и без того впечатляющему функционалу AutoVirt прибавление!
Стала поддерживаться интеграция с NetApp SnapMirror:
можно как импортировать существующие настройки, так и создавать новые “зеркальные” пары. Кроме того, можно обеспечить автоматизированный или ручной failover через глобальное пространство имен AutoVirt.
Управление NetApp SnapLock:
- через функционал архивирования можно перемещать (на основе фильтров) файлы из любой файловой “шары” на том с включенным SnapLock.
- можно также импортировать настройки SnapLock и управлять опциями через GUI AutoVirt
Обе возможности должны быть интересны владельцам NetApp. Причем политики миграции данных на SnapLock том могут заметно упростить жизнь при планировании инфраструктуры. Далеко не все данные необходимо хранить неизменными, поэтому нужно каким-либо образом отправить на SnapLock том только определенные файлы и здесь серьезным подспорьем будет AutoVirt.
Помимо различных замечательных возможностей в работе с дисковыми устройствами, в версии vSphere 4.1 несколько изменилась и работа с оперативной памятью – появилась функция “Memory Compression” (сжатие страниц-кандидатов на попадание в своп), которая в определенных случаях может заметно помочь. Срабатывает она только в моменты “перенасыщения” памяти (over-commintment), поэтому на нормальную работу (мы же не будем специально загонять себя в такой режим?!) она не влияет, но как только появляется потребность сбросить страницы в своп на диске (рис b), начинает работать memory compression. Обоснование ее использования состоит в том, что процедура распаковки сжатой страницы из специально отведенного пула (рис c) займет гораздо меньше времени, чем “вытаскивание” ее из своп-файла на диске:
Подробности можно прочитать (с картинками, но без диалогов) в соответствующем обновленном документе от VMware. Там же есть и некоторые результаты тестов. В частности, показано как memory compression улучшает результат Swingbench (вернее снижает степень его деградации при перенасыщении памяти):
Из графика видно, что число обращений к swap-файлу понижается в несколько раз.
Попытки сделать стандартный тест (бенчмарк) для систем виртуализации делались уже давно, но единого общего знаменателя я не встречал. 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 вообще никак на доступности сервисов не отражается – вторая половина зеркала берет всю нагрузку на себя.
И вот тут-то админ и понял, что значит завоевать уважение и благосклонность начальства – бюджет решения был минимизирован, имеющееся оборудование было полностью задействовано, отказоустойчивость повысилась многократно. Теперь можно и в отпуск отпроситься, не опасаясь что через два дня срочно вызовут, да и обругают за то что ничего не работает.
Вот такая вот сказка получилась. Правдивая? По моему мнению - более чем!
Как-то уже давно на TED-е видел интересную презентацию о мотивации (ссылку искать лень). Там приводился интересный пример, когда большое финансовое вознаграждение служило отличным стимулом к выполнению простых (рутинных) заданий, но создавало серьезные сложности при решении сложных, требующих творческого подхода. В принципе, (по трезвому размышлению) это вполне логично, хотя с такой позиции на вопрос мотивации я никогда до этого и не смотрел. Однако на днях я случайно узнал что оказывается уже 100 лет назад все это исследовали на мышках американские ученые Р. Йеркс и Дж. Додсон. И с тех самых пор даже появился закон Йеркса-Додсона. Мышек электрическими разрядами “стимулировали” к прохождению лабиринта. Оказалось, что чем сложнее задача, тем меньший заряд нужен для решения (сложность увеличивается в порядке II->I->III):
Ярко выраженный минимум на кривых показывает, насколько важно не переборщить с пряником и кнутом, стимулирующими к поиску решений. А исследования, результаты которых можно найти на TED’е, говорят что от мышек мы не так уж сильно и отличаемся :)
Последний рубеж взят – для x86 серверов IBM появился контроллер ServeRAID M5025. Теперь SAS 2.0 6Gbps можно использовать везде – и внутри сервера, и во внешних СХД, и в JBOD. Последний вариант и стал возможен благодаря этому контроллеру. Сами JBOD доступны с момента анонса DS3500: это EXP3512 и EXP3524, а теперь есть и RAID контроллер с внешними портами:
В комплекте, как и у младшего брата (M5015, у которого порты смотрят внутрь), есть батарейка. Кратко по характеристикам и возможностям:
Контроллер построен на базе чипа LSI SAS2108 (RAID on Chip)
512МБ кэш-памяти на борту
Поддерживается подключение до 240 дисков (до 9ти шасси с дисками на порт)
Можно создать до 64 томов (LUN)
Размер одного LUN ограничен 64ТБ
Одновременное использование SAS и SATA дисков поддерживается, но смешивать диски в одном массиве нельзя.
Стандартно поддерживается RAID 0, 1, 10, 5 и 50 (уровни 6 и 60 становятся доступны после покупки M5000 Advanced Feature Key)
ServeRAID M5025 это фактически копия LSI MegaRAID SAS 9280-8e, так что остальную информацию можно посмотреть на страничке оригинала.
Citrix XenDesktop активно набирает популярность как решение для виртуализации десктопов (VDI). Не удивительно, что если мы принимаем решение перевести сотню (а то и не одну) пользователей в виртуальную среду, отказоустойчивость решения должна быть на высоте – потери от возможной остановки существенно выше, чем поломка одного ПК в офисе. При развертывании XenDesktop активно используется Citrix Provisioning Services (PVS) и высокая доступность этой компоненты является критичной для всего решения. Существует целый ряд возможностей по защите PVS:
репликация
LUN в режиме “только чтение”
общий доступ посредством CIFS/NFS (общие папки на серверах Windows, NAS устройства)
Однако, все эти решения имеют довольно существенные недостатки:
Репликация, во-первых, требует значительных дополнительных работ по администрированию. Во-вторых, репликация не обеспечивает высокую доступность базы данных PVS (а ведь она также необходима!). Невозможно также консолидировать файлы с write cache – его придется всегда хранить локально. Наконец, в таком режиме коэффициент полезного использования дискового пространства крайне мал из-за многократного дублирования информации.
Использование LUN в режиме “только чтение” позволяет повысить утилизацию дисковых ресурсов, но администрирование такого решения становится еще более нетривиальной задачей – любое внесение изменений потребует перевода LUN в режим Managed Read-Only и, как следствие, в это время доступ к LUN будет иметь только один из серверов PVS. Но по-прежнему для обеспечения высокой доступности базы данных потребуется отдельное решение.
Использование CIFS/NFS является наиболее простым и функциональным вариантом, однако узким местом может стать ограниченная производительность и масштабируемость. Кроме того это решение, как и уже упомянутые, не обеспечивает отказоустойчивость базы данных PVS.
Но есть и еще одно решение, которое позволит решить практически все проблемы, характерные для вышеперечисленных вариантов – совместное использование CIFS (на базе Windows Server) и Sabolic Melio Suite. Какие же преимущества у данного подхода?
Как и в случае с использованием только CIFS, любой из серверов PVS имеет доступ к данным как на чтение, так и на запись.
Файлы write cache можно хранить на общем ресурсе.
Sanbolic Melio 2010 обеспечивает более высокую производительность, так как теперь можно просто увеличить число файловых серверов – так как они работают параллельно, производительность системы будет фактически ограничена только производительностью дисковой подсистемы. А благодаря использованию “страйпинга” можно увеличивать производительность и еще больше. Зеркалирование позволит, при необходимости, повысить отказоустойчивость, защитившись от сбоя в т.ч. и целой СХД.
Возможность динамического расширения дискового пространства без какого-либо влияния на работу пользователей является еще одним огромным плюсом – любой администратор понимает, что выделить “окно” для обслуживания становится с ростом пользователей все сложнее и сложнее.
Помимо обеспечения высокой доступности дисковых ресурсов, Melio 2010 предоставляет уникальное решение (AppCluster) для обеспечения высокой доступности сервера SQL (базы данных PVS).
Поддержка VSS решает упрощает резервное копирование и позволяет быстро восстановить систему после сбоя.
В разговорах я часто слышу примерно такие слова “XenDesktop? Очень интересное решение, мы думали, но обеспечить отказоустойчивость для PVS сложно, поэтому пока отказались”.
Как видите, решение есть! Да, конечно, оно стоит денег, но, во-первых, не так уж и много, а, во-вторых, это решение замечательно работает и снимает существующие ограничения других подходов!
