Контейнеры уже наделали много шума за последний год — в свое время даже про виртуализацию говорили меньше. Популярность их, безусловно, не случайна — многие решения можно построить на основе микро-сервисов. Многие разработчики поддерживают такой подход (и именно от них идет столько шума про контейнеры). Той изоляции, которую предоставляет виртуализация уже недостаточно — слишком много накладных расходов, чтобы изолировать каждый сервис, контейнеры обеспечивают гораздо большую эффективность в плане затрат ресурсов.
Многие наверное еще осенью слышали обещание 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?
Почему столь любимый и везде навязываемый микрософтом bing в ответ на запрос "microsoft explorer 9" выдает что угодно, кроме ссылки на страничку с этим самым explorer? А вот в google первая же ссылка направляет туда куда нужно!
Мы рады пригласить Вас на семинар, проводимый компаниями Microsoft и Тринити, посвященный теме:
«Построение систем высокой доступности»
Одна из основных задач IT – это повышение доступности сервисов, которые предоставляются пользователям. Данный круглый стол посвящен теме построению систем высокой доступности с помощью технологий виртуализации компании Microsoft и ее партнеров. В рамках семинара будут рассмотрены как решения Microsoft, так и сторонние прикладные решения, расширяющие их функционал.
Мероприятие состоится 19 октября - (с 09:30-13:00) по адресу ул. Крылатская, д.17, корп. 1., бизнес центр «Крылатские холмы»
Программа:
09:30 – 10:00 Утренний кофе, регистрация 10:00 – 11:30 Как построить систему высокой доступности и нужна ли для этого виртуализация? 11:30 – 12:00 Перерыв на кофе 12:00 – 13:00 Средства повышения доступности приложений в виртуальной среде Microsoft Hyper-V
Будем рады видеть Вас!
Участие в семинаре бесплатное, просьба для регистрации направить письмо по адресу s.sosunova@trinitygroup.ru.
Сегодня заключительная (четвертая) часть серии заметок про управление файловыми серверами. Речь пойдет уже не столько про глобальное пространство имен файлов, а про дополнительные возможности, возникающие в результате его внедрения. Часть 1-ая Часть 2-ая Часть 3-я
Политики управления данными.
Основной плюс AutoVirt - это возможность не просто создать глобальное пространство имен, но и обеспечить управление неструктурированными данными на основе предопределенных администратором политик. Представьте, что Вам нужно перенести все файловые ресурсы с нескольких старых серверов на новый. А если все эти ресурсы активно используются? А если нужно сохранить ссылки на ресурсы неизменными, а DFS не используется? А если нужно не только перенести данные, но старые серверы вообще вывести из обслуживания, либо использовать для других нужд? Любое из этих "если" добавляет головную боль. Вот здесь преимущества от использования AutoVirt и глобальной системы имен файлов выходит на первый план! Нам достаточно добавить новую политику (Migration) через web-интерфейс, выбрать что и куда мы хотим перенести, задать время и подождать окончания процесса. Все! Больше ничего делать не нужно. Пользователи не заметят вообще ничего. Более того, если исходный файловый ресурс имеет громадный объем и сильно нагружен, мы можем задать предварительное копирование данных в удобный нам интервал времени (вероятно это будет ночь). В это время файлы будут постепенно копироваться на новый ресурс, тогда в момент фактической миграции потребуется скопировать только изменившиеся с момента предварительной синхронизации файлы и переключить пользователей на новый сервер (еще раз отмечу, что все это делается без участия администратора). Важно, что корректно будет произведена не только миграция самих файлов, но и всех прав доступа (ACL). Если необходимо осуществить миграцию настолько большого объема данных, что два стандартных Data Engine (про них подробнее написано во второй части) не справляются с поставленной задачей за приемлемое время, то достаточно просто добавить нужное количество серверов на время миграции (никаких дополнительных лицензий для этого не потребуется). Так как DataEngine работают независимо, то рост их числа практически линейно увеличит скорость миграции (если конечно сам файловый сервер справляется с такой нагрузкой).
Но миграцией возможности AutoVirt не ограничиваются - список политик включает в себя:
Measure - это просто отчет о том как используется дисковое пространство (число файлов, их объем и т.п.). Позволяет оценить требования к ресурсам для дальнейших операций по миграции/репликации.
Copy - копирование данных. Отличается от миграции тем, что не происходит переключение пользователей на новый ресурс. Зато можно отфильтровывать файлы по типу. Это довольно ограниченная по возможностям политика, так что если нужны дополнительные функции следует использовать Replication.
Replication - пожалуй, самая "продвинутая" по возможностям опция. Именно она при миграции с DFS будет альтернативой использованию DFS-R.
Несколько слов подробнее про каждый из типов репликации: Клонирование "один источник - один клон" предназначено для обеспечения отказоустойчивости. Данные "мастера" реплицируются на удаленную площадку, а в случае сбоя происходит перенаправление клиентов на реплику. Отношение "один источник - много клонов" удобно для организации с множеством филиалов, в каждым из которых необходимо обеспечить доступность однотипных материалов в режиме чтения. Это позволит сократить расходы и снизить загрузку каналов связи. В случае сбоя, запросы будут перенаправлены на ближайший к клиенту сервер. Если в организации много филиалов и стоит задача централизованно хранить данные, то замечательно подойдет третий вариант - "много источников - один клон". В случае сбоя на удаленной площадке, failover будет индивидуальным для каждого филиала (т.е. отсутствует влияние на остальных - они продолжат работу в обычном режиме). Во всех описанных вариантах, для восстановления после сбоя следует использовать миграцию, чтобы произвести обратную синхронизацию данных и осуществить переключение пользователей на исходный ресурс.
И, наконец, последняя политика Deletion - удаляет все исходные данные после успешной миграции. Политика простая, но применяется крайне редко (ввиду очевидного риска).
Для всех политик можно задать так называемый "тихий час", когда никакие действия производиться не могут - например в периоды максимальной загрузки системы. Это позволяет избежать излишней нагрузки и обеспечить максимально комфортную работу пользователей.
Простая интеграция в инфраструктуру, весьма продвинутые возможности по обеспечению высокой доступности (как самой глобальной системы имен, так и непосредственно файловых ресурсов), набор удобных политик для управлению ресурсами, полная поддержка ACL при любых миграциях/репликациях, а также интуитивно понятный интерфейс - все это делает продукт по настоящему уникальным.
Наверное лишним будет упоминать, что Тринити является партнером AutoVirt в России. Так что куда обращаться за дополнительной информацией, а также по вопросу пилотных инсталляций Вы наверняка догадываетесь. :)
А для тех, кто продолжает использовать в своей инфраструктуре Brocade StorageX (и имеет оплаченную поддержку), есть очень заманчивое предложение – до 30 июня 2010г. действует специальная акция со скидками при замене лицензий StorageX на AutoVirt.
Очередная (третья) часть небольшой серии заметок про то как можно упростить управление файловыми серверами. Вчера было рассказано про отказоустойчивость и общую схему. Сегодня речь пойдет про две другие возможности:
"Прозрачное" внедрение в инфраструктуру.
Добавление файлового сервера под управление AutoVirt делается в два этапа:
На первом происходит просто сканирование файловых ресурсов, а самому серверу присваивается новое, "виртуальное" имя. При этом, никаких изменений в инфраструктуре в этот момент вообще не происходит - сервер остается доступен всем клиентам. Все файлы на нем также доступны со своими привычными UNC именами. По-умолчанию, виртуальное имя сервера отличается от “настоящего” приставкой "av-", впрочем, его можно задать и совершенно произвольно (главное, чтобы другого сервера с таким именем не было). Теперь ко всем ресурсам файлера можно также обращаться, используя не только привычное UNC имя, но и виртуальное имя сервера. На практике это конечно не нужно, но зато дает возможность убедиться в том, что сервер AutoVirt нормально функционирует и можно приступать ко второму этапу. На картинке видно, что у нас есть Dependent (зависимое) пространство имен - это означает, то ресурсы хотя и доступны через сервер AutoVirt, но они "привязаны" к физическому серверу и пока еще не могут быть перенесены с него на другой файлер.
Для того, чтобы полностью виртуализировать файловый ресурс (например \\fileserver) и "отвязать" его от "железа", необходимо запустить так называемый процесс "Cutover". Физически он сводится к тому, что мы (под руководством AutoVirt) меняем имя сервера на новое, а запросы к изначальному имени перенаправляются с этого момента на сервер AutoVirt. Собственно это и есть единственный перерыв в обслуживании - смена имени сервера требует его обязательной перезагрузки. Все остальное время все ресурсы сервера доступны пользователям в полном объеме! Т.е. время простоя сервиса составляет всего несколько минут! Теперь любой запрос к \\fileserver будет происходить через AutoVirt, который переадресует его на нужный сервер (либо на оригинальный, либо же на любой другой сервер, если была осуществлена миграция данных).
После такой несложной процедуры нам становятся доступны все прелести глобального пространства имен! Мы можем запустить процесс миграции данных на другой сервер, мы можем настроить репликацию данных между серверами и много чего еще, но об этом ниже.
А как быть, если нам потребуется отказаться от AutoVirt (всем система хороша, но бюджет на нее выделили только на следующий год)? И это тоже очень просто - достаточно произвести еще один Cutover, чтобы вернуть все на круги своя. Правда здесь уже нужно быть осторожнее - если была осуществлена миграция данных, процедура не столь тривиальна (иначе данные перестанут быть доступны по привычным UNC именам).
Поддержка DFS.
В AutoVirt есть также и поддержка Microsoft DFS. Реализована она полностью аналогичным образом, что и виртуализация файловых серверов. Сначала DFS испортируется, а потом необходимо произвести переключение на AutoVirt. После этого DFS уже больше не используется, а весь функционал глобальной системы имен ложится на плечи AutoVirt. Важно помнить, что состояние DFS отображается на момент импорта и не синхронизируется повторно, в случае внесения каких-либо изменений в DFS. Поэтому если стоит задача перейти от DFS к AutoVirt, не следует это делать параллельно с активным редактированием DFS - либо одно, либо другое. Добавление новых ресурсов в независимый Namespace делается очень просто - перетаскиванием нужных ресурсов мышкой. DFS для функционирования AutoVirt не нужна (благо AutoVirt предоставляет гораздо больше возможностей), а миграция может быть осуществлена предельно просто и быстро.
Подробный рассказ о главных преимуществах AutoVirt ждите в заключительной части. А пока (для затравки) сравнение возможностей с DFS:
Это продолжение ранее начатой короткой серии заметок про управление файловыми серверами.
Так какие же есть альтернативные (предлагаемому Microsoft DFS) решения, чтобы удобно, просто и по возможности прозрачно для существующей инфраструктуры получить глобальное пространство имен? Рассказ пойдет о продукте компании AutoVirt. Первое, что бросается в глаза, - это не надстройка и не дополнение к Microsoft DFS. AutoVirt является совершенно самостоятельным решением и для его работы не требуется ни DFS, ни DFS-R - нужен только домен и конечно сами файловые серверы. Какие положительные качества решения можно выделить:
отказоустойчивость "by design"
прозрачное внедрение в инфраструктуру без необходимости что либо менять у пользователей
поддержка DFS
различные политики, обеспечивающие управление данными (миграция, репликация и т.п.)
Сначала немного остановимся на принципах работы, а затем я постараюсь подробнее описать каждую из "особенностей" AutoVirt. Реализация глобальной системы имен основана на перенаправлении DNS запросов. Обычно, при обращении к папке на сервере, когда мы набираем \\A\myshare, сначала идет запрос к серверу DNS, который нам возвращает IP адрес сервера "A". А уже потом мы с этого файл-сервера получаем необходимые нам данные:
Глобальная система имен в AutoVirt работает почти также, только теперь разрешением имен занимается не DNS, а сервер AutoVirt, на который DNS сервер и перенаправляет все запросы:
Благодаря такому подходу, становится возможным динамически менять ссылки на ресурсы без каких-либо видимых последствий у пользователей - если все данные были перенесены на сервер "B", то достаточно изменить ссылку на уровне сервера AutoVirt и пользователи будут уже обращаться к новому серверу, а старый можно выводить из обслуживания. Так ведь и Microsoft DFS работает точно также, скажете Вы! Где научная новизна?! Где преимущества? За что деньги-то платить? И будете правы (но лишь отчасти) - сама по себе глобальная система имен работает примерно одинаково у всех производителей. Дьявол кроется, как обычно, в деталях. Давайте к ним и обратимся!
Отказоустойчивость и схема работы.
Совершенно очевидно, что для обеспечения нормальной работы пользователей необходима высокая доступность Global Namespace (глобального пространства имен). AutoVirt имеет встроенные возможности кластеризации (т.е. нет никакой необходимости ни настраивать Microsoft Cluster, ни платить за Enterprise лицензию Windows Server). Более того, настоятельно рекомендуется развернуть сразу два сервера AutoVirt в кластере. Настройка кластеризации происходит автоматически, при установке ПО - ничего для этого делать дополнительно не нужно. Полностью поддерживается установка в виртуальной инфраструктуре, более того, в большинстве случаев рекомендуется изначально идти именно по такому пути (по крайней мере на сравнительно небольших инсталляциях).
Концептуально схема AutiVirt выглядит так:
Политиками (Policy Engine) в каждый момент времени управляет только один сервер, но в случае его сбоя, управление будет передано на вторую машину. Policy Engine фактически управляет всей работой комплекса. Data Engine (DE) - это процессы, обеспечивающие всю "грязную работу" - миграцию и репликацию данных, т.е. все действия связанные с физическим передвижением файлов между системами. DE работают на обеих машинах одновременно. Более того, если производительности для какой-то глобальной миграции данных недостаточно, то число серверов DE можно увеличить. Скажем, для ускорения миграции файлов на только что закупленный NAS, можно на время увеличить число Data Engine, тем самым практически пропорционально сократив время миграции. Client Referrals, в свою очередь, отвечает на запросы клиентов. Процесс работает параллельно на нескольких серверах. Если в компании есть удаленные офисы, где работает свой сервер AD, то рекомендуется в них разместить дополнительные серверы AutoVirt, чтобы обеспечить бесперебойную работу клиентов в случае обрыва каналов связи.
Управление AutoVirt'ом осуществляется через простую и интуитивно понятную WEB-консоль, никакого дополнительного ПО (кроме браузера с поддержкой SilverLight) администратору не требуется:
Прямо на главной странице представлен спектр возможностей, а также последовательность действий для достижения необходимого результата, так что даже не читая документацию можно быстро разобраться что к чему.
Про остальные преимущества и возможности AutoVirt в плане прозрачной интеграции в уже имеющуюся инфраструктуру рассказ будет продолжен завтра.
Очевидцы пишут, что любовь ушла. В том смысле, что 2008R2 станет последней версией для процессоров Intel Itanium. Поддержка сохранится до 2013 года (а расширенная поддержка еще 5 лет), так что все в рамках стандартов Microsoft. Однако новых версий ждать не стоит (равно как не будет новых версий SQL Server и Visual Studio).
Основная озвученная причина – стремительная эволюция систем x86 (не только в плане производительности, но и в плане отказоустойчивости). Кроме того, поставки Windows на Superdome всегда были очень незначительными по сравнению с HP-UX и OpenVMS. Слишком медленное развитие Itanium (как и постоянные, но объявляемые “запланированными” задержки с выпуском процессоров), как мне кажется, играли в данном решении отнюдь не последнюю роль.
Стоит напомнить, что Microsoft не первый - в RedHat не так давно также отказались от дальнейшей поддержки систем на базе Itanium. Второй большой линуксовод (Novell) продолжает поддерживать IA64, но как долго это еще продлится?
Что дальше? HP столько лет всеми силами отстаивала процессоры Itanium, что отказываться от них конечно теперь не будут, но вот останутся ли другие производители или для Intel будет теперь только один покупатель на Itanium?
С завидным постоянством вижу вот такого плана вопрос:
“Мы установили дисковую систему, создали один 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. А купить и/или получить более подробную информацию, как обычно, можно у нас. :)
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$ дополнительно за каждого следующего пользователя (без учета стоимости поддержки).
За прошедшее время много было новостей: Oracle купил SUN, анонс vSphere..
Но хочется не об этом, а просто занести в заметки некоторые интересные моменты:
- по проводу покупки Sun лучше всех "прошелся", на мой взгляд, Marc Farley:
Вот совсем недавно The Tolly Groupопубликовали сравнительное тестирование Citrix XenApp под XenServer и Vmware ESX. Победил Xen, а со стороны vmware было одобрение публикации (как этого требует лицензия vmware). Но если вспомнить другое сравнительное тестирование, там проигравший Citrix проигнорировал приглашение принять участие. Интересно как будет обстоять аналогичное соревнование при использовании vSphere?
Что касается vSphere, то очень важным (разумеется всякие инфраструктурные изменения тоже очень и очень важны, но..) мне видится возможность использовать до 8ми процессорных ядер внутри одной VM. Теперь стало можно виртуализировать и заметно более требовательные к процессорным ресурсам машины.
Citrix, тем временем, выпустил tech preview бесплатной утилиты XenConvert для переноса физических и виртуальных машин (из других форматов, в том числе и vmware) в формат XenServer. Те, кто соблазнился на бесплатность XenServer супротив vmware, смогут совершенно спокойно перенести виртуальные машины в новую среду.
Также хочется упомянуть попавшуюся на глаза ссылку об изменениях в Windows Server 2008R2 по сравнению с версией 2008.
Первая версия Microsoft MED-V вышла уже больше недели назад, но еще наверное не слишком поздно считать это новостью.
Я все-таки собрался с силами повнимательнее почитать, какие возможности (а главное, для чего) предоставляет этот продукт. По сути своей, это надстройка над бесплатным Virtual PC, которая существенно упрощает контроль и управление созданными образами виртуальных машин. Кроме того, от пользователя можно "спрятать" сам факт наличия виртуальной машины и для него приложение, к которому он имеет доступ будет видно так, как будто бы оно установлено на локальной машине. Можно сказать, что это прямая альтернатива VMware ACE. Однако, скажу честно, острой необходимости и большой популярности я у этого решения не вижу. Основное направление для этого продукта с точки зрения Microsoft - позволить запускать приложения, написанные для устаревших ОС (Windows XP или Windows 2000), что конечно актуально в свете желания все-таки раскрутить висту до должной популярности (да и Windows 7 не за горами), но очередей из желающих внедрить у себя в инфраструктуре MED-V я что-то не видел. Среди плюсов - тесная интеграция с Active Directory, но, с другой стороны, это можно назвать и существенным недостатком - даже "чужие" пользователи, которым необходимо дать приложение лишь на время, должны будут быть заведены в AD. Пишут, что может быть в будущих версиях и будет другая аутентификация, но без четких планов и сроков. Раздача образов осуществляется через IIS, соответственно, можно делать реплики в удаленных офисах, существенно сокращая интернет-трафик. Одно из основных преимуществ это, на мой взгляд, централизованное обновление - достаточно обновить только оригинальный образ и не потребуется делать больше ничего на каждой из пользовательских машин. За подключение пользователей (авторизацию и т.д.) отвечает Management Server, который является центральным компонентом продукта. Каждый Management Server способен обслуживать до 5000 пользователей. В случае, если их число больше - можно использовать несколько Management серверов, но в этом случае они будут совершенно независимыми (у каждого свой набор политик и т.п.).
Продукт безусловно занятный (и наверное для некоторых компаний и полезный), но меня больше всего в данном случае заинтересовала лицензионная составляющая и я попытался понять, про что нужно помнить потенциальному заказчику. На сайте http://www.microsoftvolumelicensing.com/userights/ можно увидеть, что использовать еще одну копию ОС в виртуальной среде (а именно это мы и делаем в MED-V) можно только если у нас установлена версия Windows Vista Enterprise Edition (причем, "виртуальных" может быть не более 4). "Счастливые" обладатели Windows Business могут либо прикупить еще лицензий, либо доплатить за SA (Software Assurance) - в этом случае они будут иметь право установить Vista Enterprise и получат вышеописанные привелегии. В свете того, что SA используется не так уж и часто, а Enterprise и того реже, нужно помнить про необходимые затраты при внедрении MED-V. (Если кто-то хорошо разбирается в лицензировании Vista и увидел в моих словах ошибки - буду рад любым комментариям!)
