12-го октября мы вместе с коллегами из HP будем проводить довольно интересную конференцию в Санкт-Петербурге. Называется она “Практика построения ЦОД нового поколения”. Расказывать будут много нового. Регистрироваться можно здесь.
Если будет свободный день то, постараюсь поехать на эту конференцию, чтобы пообщаться с коллегами и посмотреть на новые чудеса ИТ технологий.
Виртуализация становится все более распространенной технологией консолидации серверного парка. Многие организации к ее широкому применению подтолкнул кризис. По данным IDC в последнем квартале 2009 года было выпущено 350000 серверов, из которых было виртуализировано 18,2%.
На первый взгляд виртуализация замечательна со всех сторон т.к. позволяет оптимизировать утилизацию оборудования и повышает гибкость инфраструктуры. Но если присмотреться внимательно, то выясняется, что у нее есть и неочевидные отрицательные эффекты.
Давайте посмотрим на один из них. Как только технологии виртуализации становятся доступны достаточно большому количеству людей в организации, возникает эйфория. Теперь развернуть набор виртуальных машин с нужными сервисами на порядок легче, чем физический сервер. Ресурсы кажутся практически неограниченными, поэтому каждый отдел начинает разворачивать свои виртуальные машины. В этот момент начинается бесконтрольное размножение виртуальных машин. Через какое то время все запутываются в том кому, что теперь принадлежит, кто отвечает за конкретную виртуальную машину и где она находится. В результате с течением времени внутри вашей инфраструктуры появляется очень много бесхозных виртуальных машин. Часть из них продолжает работать бесконтрольно, какие то из них выключены, а некоторые месяцами находятся в спящем состоянии. В связи с тем, что обновление этих тестовых виртуальных машин не настроено, получается, что внутри инфраструктуры появляются точки не подверженные действию корпоративной политики безопасности. Если в организации не налажен процесс управления конфигурациями и изменениями довольно скоро в ней начнутся инциденты с безопасностью.
Все методы, о которых я буду писать ниже, в основном относится к Windows виртуальным машинам, но частично применимы и для Linux/Unix.
Бороться с проблемой отсутствия обновлений внутри виртуальных машин можно комбинацией нескольких способов. Внедрением единой системы хранения образов развертывания виртуальных машин, например библиотеки SCVMM. В шаблонах виртуальных машин уже заранее должны быть прописаны способы автоматического обновления. Для того чтобы владелец виртуальной машины не мог отключить в ней агент обновления можно применять технологию Network Access Protection которая позволяет помешать физические и виртуальные машины в карантин если они не соответствуют политикам нашей сети. Одной из политик может быть работа в системе агента обновлений и срок последнего обновления не старше чем X дней или часов. Таким же образом можно контролировать наличие в системе антивируса, его обновления и статус и прочих необходимых нам системных процессов.
Проблему поддержания включенных виртуальных машин в обновленном состоянии эти меры решают. К сожалению, на данный момент ни WSUS, ни SCCM умеют обновлять лишь системы находящиеся во включенном состоянии. А как быть с эталонными виртуальными машинами, хранящимися в библиотеке SCVMM или машинами, находящимися на хостах Hyper-V в состоянии паузы? Обычно на сленге такие машины называются “спящими”. Они могут пребывать в таком состоянии месяцами. Все это время обновления на них не устанавливаются. В момент включения такие машины потенциально могут послужить плацдармом для атаки или распространителями эпидемии.
Для поддержания этих систем в актуальном состоянии нам как раз пригодится Microsoft Offline Virtual Machine Servicing Tool он же OVMST. Этот инструмент позволяет выполнять следующие задачи:
Чтобы понять, как работает OVSMT, давайте посмотрим на типовую архитектуру инфраструктуры необходимой для обслуживания “спящих” виртуальных машин.
Как видите в нашей инфраструктуре присутствуют библиотека и сервер SCVMM, сервер для обслуживания виртуальных машин, сервер обновлений WSUS или SССM. Стоит отметить, что все эти хосты обычно изолированы от основной сети с помощью VLAN. Доступ в основную сеть имеет только хост с SCVMM. В этом случае он является шлюзом между VLAN.
Сделано это для того чтобы виртуальные машины которые мы будем обновлять не смогли подвергнуть риску основную сеть обмениваясь в ней данными в процессе установки обновлений.
Давайте пошагово посмотрим как происходит обновление виртуальных машин?
1. Чтение данных из библиотеки SCVMM и выбор виртуальных машин, шаблонов, дисков
2. Поиск «спящих» виртуальных машин на хостах Hyper-V подключенных к SCVMM
3. Создание групп обслуживания и помещение в них виртуалных машин, шаблонов дисков собраных на первом и втором шагах
4. Перенос «спящих» виртуальных машин с хостов Hyper-V или развертывание их из шаблонов хранящихся в библиотеке SCVMM на хостах Hyper-V предназначенных для обновления гостевых ОС.
5. Пробуждение или включение обновляемых машин на обслуживающем хосте Hyper-V
6. Принудительная проверка обновлений необходимых виртуальной машине
7. Применение обновлений к виртуальной машине
8. Проверка статуса обновлений
9. Выключение виртуальной машины, при необходимости подготовка к помещению ее обратно в библиотеку SCVMM с помощь sysprep
10. Возвращение вирт. машины на хост где она первоначально находилась или помещение ее в библиотеку откуда мы ее взяли
Итак мы разбрались в механизмах работы OVMST пошаговый алгоритм настройки этого коплекса я опишу в следующей части статьи, а пока вы можете ознакомиться с вебкастом об OVMST.
У меня наконец-то дошли руки написать о том, как виртуализировать SCO OpenServer. Все что я буду писать ниже актуально и для SCO UnixWare.
Когда я решил заняться виртуализацией этой ОС многие коллеги недоумевали над тем какая муха меня укусила. Понятно, что ты периодически рассказываешь о жизни Linux под Hyper-V, но зачем берешься за такую древность как системы от SCO? Некоторые ИТ специалисты даже удивлялись, что компания SCO до сих пор жива и чувствует себя вполне нормально. Они думали, что после банкротства в 2007 году компания перестала существовать.
Ответ на эти вопросы очень прост. История компании SCO насчитывает не один десяток лет и хранит в себе следы взлетов и головокружительных падений. Долгое время SCO была одним из главных поставщиков Unix ОС для крупнейших компаний этой планеты. В результате деятельности SCO ее ОС внедрены и работают по сей день в 87 странах. Общее количество ныне работающих серверов OpenServer приблизительно 2 миллиона. Традиционно потребителями продукции этой компании являются финансовые учреждения, силовые структуры, государственные организации и телеком компании.
Думаю вы согласитесь что перечисленные выше организации весьма консервативны и зачастую не склонны тратить деньги в погоне за новыми веяниями в ИТ индустрии. Поэтому у многих из них до сих пор функционирует SCO OpenServer или SCO UnixWare. Под эти ОС написано множество ПО, которое успешно работает. Переписывать его никто не собирается. Более того часто складывается ситуация что миграция на более современные ОС и портирование ПО потребует таких затрат что затея становится экономически невыгодной.
Но есть одна проблема аппаратное обеспечение серверов на которых установлена ОС OpenServer постепенно изнашивается и приходит в негодность. Находить сменные комплектующие не так уж и просто, да и цены на сертифицированное SCO оборудование не выглядят дешевыми. А тем временем производители аппаратного обеспечения на основе серверов с процессорной архитектурой x86 не зря едят свой хлеб и выпускают все более мощные конфигурации серверов, постоянно снижая цены. Получается, что удобнее консолидировать экземпляры работающих ОС от SCO на более мощном оборудовании с помощью виртуализации. Вдобавок к выгодам от оборудования мы получаем резервное копирование с помощью SC DPM, отказоустойчивую кластеризацию с Live migration и централизованное управление с помощью SC VMM.
Делается это довольно легко. Читаем документ вот тут http://www.sco.com/products/openserver507v/hyperv/
Скачиваем эталонный образ виртуальной машины SCO OpenServer 5.0.7V для Hyper-V
Обратите внимание на букву V в названии версии она означает что данная версия ОС содержит драйвера необходимые для работы под управлением системы виртуализации.
После скачивания распаковываем виртуальную машину и импортируем ее в Hyper-V
Как видите по умолчанию ресурсов ей выдано довольно мало. Версия 5.0.7V поддерживает до 4ГБ ОЗУ так что если для выполнения ваших задач необходимо больше памяти дайте ее виртуальной машине..
После запуска система начинает автоконфигурирование
Сетевые настройки можно задавать статически или с помощью DHCP. Оба способа работают одинаково хорошо.
Затем нужно настроить систему безопасности, создать пароли и при желании установить дополнительные языки. Делается это очень просто поэтому останавливаться на этом не буду.
После окончания установки и перезагрузки на экране увидим следующее.
Сеть, видео и прочие устройства работают вполне надежно и отлично справляются со своими функциями.
Сеть я тестировал побродив по сайту Microsoft. Затем установил пакет Samba и с помощью него передал между SCO OpenServer и Windows несколько десятков гигабайт разных файлов. На это пришлось потратить довольно внушительное время т.к внутри виртуальной машины доступен сетевой адаптер с пропускной способностью 100 мбит которого вполне хватает для выполнения большинства задач. Зато теперь могу сказать что сетевая подсистема работает как часы.
Обратите внимание что потребление ресурсов процессора при этом минимально.
Как мигрировать приложение из существующих в вашей инфраструктуре серверов в виртуальные описано тут http://ds45.blogspot.com/2009/07/sco-p2v-in-real-life.html
На этом рассказ о виртуализации SCO OpenServer можно заканчивать. Надеюсь он пригодися вам если вы решите сэкономить на поддержке унаследованных Unix систем.
Виртуализация основных бизнес приложений все сильнее и прочнее входит в нашу жизнь, меняя привычные методы управления инфраструктурой. Еще пару лет назад я рекомендовал слушателям на семинарах Techdays виртуализировать SQL Server только в случае крайней необходимости и если нагрузка на SQL не велика. Технологии не стоят на месте, и теперь виртуализация БД становится обыденностью. Более того официальную поддержку получает сценарий переноса SQL Server работающего в виртуальной машине с одного узла кластер на другой без прерывания обслуживания клиентов. Делается это с помощью механизма Live Migration. Таким образом, мы легко повышаем отказоустойчивость SQL Server.
Все это описано в документе "Planning, Implementing and Supporting SQL Server Virtualization with Windows Server 2008 R2 Hyper-V and Live Migration"
Внутри документа вы найдете четыре секции позволяющие легко выполнить планирование, внедрение в виртуальной среде или миграцию существующего SQL Server из физической среды в виртуальную. В заключении вы прочитаете о том как лучше всего управлять виртуальным SQL.
Надеюсь все что я описал, поможет вам легко и беспроблемно виртуализировать SQL
Вышло очередное обновления для Microsoft Forefront Unified Access Gateway (UAG). Установив его можно получить следующую новую функциональность:
Скачать обновление можно тут http://www.microsoft.com/downloads/en/details.aspx?FamilyID=9dcccebc-accb-4229-901a-792cc66791de.
Так же рекомендуется посетить страницу документации UAG.
Хорошо известный набор продуктов Microsoft Office Communications обрел новое имя. Таблица сответствия названия продуктов ниже.
О новых возможностях наиболее полно написано в блогах коллег. Соревноваться с ними смысла нет поэтому просто приведу ссылки.
http://blogs.technet.com/b/ai/archive/2010/09/14/rc-microsoft-lync-server-2010-ocs-vnext.aspx
http://blogs.technet.com/b/uc/archive/2010/09/13/introducing-microsoft-lync-the-next-ocs.aspx
http://blogs.technet.com/b/dodeitte/archive/2010/09/13/microsoft-lync-server-2010-rc-now-available.aspx
http://blogs.technet.com/b/ucedsg/archive/2010/09/13/next-generation-of-office-communications-server-named-microsoft-lync-server-2010-and-release-candidate-now-available-for-download.aspx
Скачать RC-версию Lync можно здесь.
Так же мы можете посмотреть демо продуктов Lync с конференции Voicecon
Рекомендуется посетить следующие сайты
Поддержка данного продукта до момента выхода RTM версии будет осуществляться через форумы:
Для развертывания в Lync в вашей инфраструктуре вам пригодится инструмент Microsoft Lync Server 2010, Planning Tool (RC). Он позволяет:
Так же рекомендую прочитать блог об управлении Lync Server с помощью Powershell.
Партнерам будут интересны следующие ресурсы:
Partner Launch-in-a-Box
MPN Lync Product Page
Надеюсь этот скромный набор ресурсов поможет вам начать работать с Lync более плодотворно.
Если вы отвечаете за компьютеры, установленные в общественные местах, то знаете, что поддерживать их в порядке - довольно трудоемкая задача. Нам нужно сделать так, чтобы пользователи не могли вносить изменения в операционную систему и установленные приложения, не могли запускать принесенные с собой приложения, получали доступ только к набору разрешенных приложений, автоматически завершали сеанс работы с системой в указанное время. А после завершения текущего сеанса или перезагрузки система возвращалась в свое эталонное состояние. Еще одна проблема - своевременное обновление системы, не мешающее работать пользователям.
Для Windows XP и Windows Vista такие функции выполняла программа Windows SteadyState. Время идет, меняются технологии, применяемые для решения насущных задач. Мы видим, что компании, использующие Windows XP и Windows Vista, постепенно мигрируют на Windows 7. Процесс еще не завершен, но идет довольно хорошими темпами. Есть надежда, что завершится он достаточно скоро. В связи с этим приложение Windows SteadyState обновляться больше не будет, в текущем состоянии оно будет доступно для скачивания до 31-го декабря 2010 года. Поддержка данного решения продлится до 30-го июня 2011 года. Так что если вам нужно это приложение, советую скачать его сейчас.
У вас наверно возник вопрос, как проблема защиты и обслуживания общедоступных ПК решается в Windows 7? Довольно просто. Практически весь функционал SteadyState теперь встроен в Windows 7. Чтобы правильно его настроить и эффективно управлять им, в дальнейшем вам пригодятся следующие документы:
Многое из того, что описано в этих документах, может пригодиться не только администраторам общественных компьютеров, но и тем, кто управляет парком ПК на предприятиях. Эти знания также можно применять для домашних компьютеров, которыми могут пользоваться ваши дети.
Надеюсь, это позволит упростить обслуживание ваших систем, сократит количество рутинной работы и даст возможность потратить время на что-то более увлекательное и полезное.
В рамках Московской User Group 13 сентября мы будем поздравлять программистов с профессиональным праздником. В рамках этого собрания выступят легендарные докладчики из команды Microsoft Patterns&Practices. Они очень хотят пообщаться с локальным сообществом и обсудить ключевые вопросы архитектуры приложений.
План встречи:
Докладчики:
Участие бесплатное.
Подробнее узнать о мероприятии и зарегистрироваться можно здесь.
Недавно я писал о выходе версии 2.1 сервисов интеграции Linux для Hyper-V. Изменений и улучшений по сравнению с прошлой версией довольно много. С появлением нового функционала изменилась и процедура установки сервисов интеграции в гостевые машины на основе Linux. Поэтому, сегодня я опишу, как устанавливать их в SLES 11. Все, что вы встретите в этом тексте одинаково актуально как для 32-х битных так и для 64-х битных версий SLES 11.
Начальная установка SLES 11 под Hyper-V довольно тривиальна. Главное не забыть выбрать опцию “Physical machine (Also for Fully Virtualized Guests)” и установить инструменты разработки “C/C++ Compiler and Tools”. Они пригодятся нам в дальнейшем для сборки модулей ядра.
Пока сервисы интеграции не будут установлены синтетический сетевой адаптер будет не доступен. Если вам нужно в этот промежуток времени работать с сетью, добавьте виртуальной машине сетевой адаптер “Legacy Network”.
После этого можно продолжать установку гостевой ОС в обычном режиме. По окончанию установки можно настроить сеть и проверить как работает доступ в Интернет.
Как видите, все отлично работает и нам доступна сеть через Legacy адаптер. На этом можно считать начальную установку гостевой ОС завершенной.
Поэтому переходим к самой сложной части – установке интеграционных сервисов, которые дадут нам возможность использовать быстрые виртуальные HDD и гигабитные синтетические сетевые адаптеры.
Скачиваем пакет Linux Integration Services 2.1. Распаковываем его и внимательно читаем инструкцию. Обратите внимание, что установка интеграционных сервисов для SLES 11 и SLES 10 SP3 довольно сильно отличается. Про установку под SLES 10 SP3 я напишу отдельную заметку позже.
Процедура установки интеграционных сервисов в официальной документации описана, по моему мнению, несколько запутано. Это затрудняет ее понимание и правильное применение. Поэтому рекомендую пользоваться мгновенными снимками Hyper-V, на случай если захочется отменить сделанные по ошибке изменения.
Отредактируйте файл /etc/modprobe.d/unsupported-modules так чтобы в нем была следующая строка:
allow_unsupported_modules 1
Перезагружаем виртуальную машину. Подключаем пакет с сервисами интеграции как DVD в виртуальную машину. В моей системе включено автоматическое монтирование, если в вашей системе не так, то возможно придется воспользоваться командой mount.
Создаем служебную директорию /opt/linux_ic и копируем исходные тексты модулей. Проводим компиляцию, устанавливаем их и перезагружаемся.
# mkdir /opt/linux_ic # cp –R /mnt/cdrom/* /opt/linux_ic # cd /opt/linux_ic # make # make install # reboot
После перезагрузки можно увидеть, что в системе появился новый сетевой адаптер seth0.
Плюс к этому нужно проверить все ли модули загрузились с помощью команд
# lsmod | grep vsc
# modinfo vmbus
· Как видите, в системе появились модули netvsc, storvsc, blkvsc, vmbus.
Затем отредактируйте файл /etc/fstab и замените все секции, начинающиеся с /dev/disk/* на эквиваленты в формате /dev/hd* чтобы содержимое файла выглядело примерно так:
/dev/hda1 swap swap defaults 0 0 /dev/hda2 / ext3 acl,user_xattr 1 1
Отредактируйте файл /boot/grub/menu.lst и измените, опции загружаемого по умолчанию ядра, так чтобы они указывали на дисковые устройства с новым наименованием:
root=/dev/hda2 resume=/dev/hda1
Приведите файл /etc/modprobe.d/unsupported-modules в первоначальное состояние, установив 0 в качестве значения опции allow_unsupported_modules.
Перезагрузите систему и наслаждайтесь выросшим быстродействием.
Для того чтобы у вас не возникло сомнений в том что SLES нормально чувствует себя под Hyper-V не только в лабораторных условиях, и пригоден для серьезных вычислительных задач, я дал виртуальным машинам по 4 процесора и как можно больше оперативной памяти. К сожалению в моем физическом сервере всего 16 гигабайт памяти, поэтому виртуальной машине удалось дать максимум 15. Что из этого получилось вы можете посмотреть ниже.
Как видите процедура установки интеграционных сервисов не так уж и сложна. Чтобы, в дальнейшем избежать ее рекомендуется клонировать виртуальную машину и в дальнейшем использовать ее как шаблон для новых машин.