Я не являюсь экспертом, а просто администрирую небольшую сеть, я как любой человек допускаю ошибки, потому описываю все не так как оно правильно должно было бы быть, а как оно было на самом деле. Так что некоторые «ляпы» допущенные мной за время проделанной работы прошу не рассматривать слишком строго.

Введение

На дворе 2012 год. Я уже три года работаю в бюджетной организации под названием муниципалитет города Томска. Если первые полгода пришлось разбираться и «въезжать» в структуру организации сети и «что» и «откуда» растет с точки зрения сетевого оборудования, то последние 2.5 года пришлось потратить на поддержку серверного «хозяйства». А его как оказалось совсем чуть-чуть: лес состоящий из 25 доменов, на каждый 1-2 контроллера + 1-2 файл-сервера + сервер с БД + роутер если подразделение подключено через стороннего провайдера (часто роль первых трех выполнял один сервер, но об этом позже). И так сложились обстоятельства, что оборудование имеет привычку стареть. При этом в последний раз покупка оборудования была в 12.01.2007 – два «новых» сервера уже заметно постарели (5 лет прошло). А выделение новых средств хватало исключительно на поддержку старых серверов, а именно зип-пакета из винчестеров на случай если один в рейде выйдет из строя. На мой постоянный вопрос: «А что мы будем делать, если накроется сама плата рейда?» бывалые администраторы разводили руками. Однако время шло, нештатных ситуаций было все больше, случалось и так, что за ночь вылетали и по два винчестера в одном рейде. Мы (коллектив комитета информатизации администрации города Томска) понимали, что надо что-то менять. Или старые сервера на новые или смотреть в сторону виртуализации.

Уровень: начинающим

Опыт использования виртуализации на VirtualBox

Введение

Несколько лет назад я начал разбираться с вируализацией, и у меня получились своего рода путевые заметки, которые я сейчас оформил и выкладываю сюда. Никаких откровений тут не будет, статья адресована начинающим админам. Задача которую я здесь решаю состоит в том, чтобы виртуализовать уже имеющиеся не виртуальные сервера на Linux и FreeBSD.

Горячее резеврное копирование, работающих виртуальных машин средствами XenServer API.
Без лишних слов, это краткое описание не самой сложной но весьма востребованной функции.

В начале года я начал заниматься попытками запустить в среде Thinstation клиент VMWare View и этот текст — результат моей работы. Это скорее даже заметка, нежели полноценная статья, так как писака из меня неважный. Кто заинтересовался — читайте далее.

Добрый день хабравчане, по роду своей деятельности нередко приходится работать с кластерными решения тех или иных программных продуктов. Но рассказывать о настройках какого либо программного продукта было бы не так информативно, поэтому поискав, и наткнувшись на сайт Юрия (за что ему огромное спасибо), я решил немножко развить эту тему и на конкретном примере посмотреть прирост производительности при вычислении числа Pi в кластерном исполнении.

Введение

На днях мой сотрудник удалил случайно несколько виртуалок в Citrix XenServer.
Все осложнилось тем что виртуальные машины оказались на snapshot дисках.
Под катом рассказываю как я их оттуда вынимал в отсутствии каких либо резервных копий и переносил на KVM.
Примеров команд много не делал, так как целью статьи было описание концепции. Внизу привел необходимые ссылки.

Перенос FreeBSD

Конкретно, речь пойдет о наиболее часто встречающейся проблеме при переносе BSD системы

Для профессионалов, знающих Linux, BSD системы понятны «по аналогии», за исключением некоторых особенностей. Об особенностях и пойдет разговор.
Да, есть великолепное руководство по FreeBSD на оффициальном сайте, и даже на русском языке оно тоже есть, но момент о котором пойдет речь описывается далеко не на первой странице, а если «падает» критически важный сервер, к которому подходил последний раз лет -цать назад (или вообще никогда), и его нужно срочно поднять на другом хосте с неаналогичной конфигурацией, то искать можно долго.
И в то же время, это те основы, без изучения которых дальше идти нельзя.

Итак, практическая задача: перенос FreeBSD на другой хост (контроллеры могут различаться: IDE/Raid ISCI/VMware ESX/Citrix Xen).

Представьте, что мощные и прожорливые десктопные приложения наподобие Photoshop, AutoCAD или современных игр, могли бы работать как веб-приложения — без длительного скачивания и установки, без привязки к конкретному устройству, и при этом сохраняли бы работоспособность даже при обрыве связи. Технология Сloudpaging от стартапа Numecent позволяет делать именно это. Cloudpaging объединяет три давно известных технологии (виртуализация приложений, динамическая загрузка страниц памяти и облачные сервисы) в нечто качественно новое. Любое Windows-приложение автоматически виртуализируется и разбивается на маленькие фрагменты-страницы, которые могут скачиваться с сервера в любом порядке. На стороне клиента виртуальный блок управления памятью загружает в RAM только те фрагменты кода, библиотеки и ресурсы, которые необходимы в данный момент, подгружая остальное с сервера по мере необходимости. Все полученные с сервера страницы сохраняются в кэше на диске, и при обрыве связи приложение продолжит работать до тех пор, пока ему не потребуется страница, которой в кэше нет.

Хочу поделиться опытом своей команды по миграции с древнего VMware Server 2.0 на ESXi 4.1. В ходе оптимизации расходов на обслуживание перед нами встала задача уйти с сильно подтормаживавшего VMware Server под виндой на бесплатный ESXi. Задача усложнялась территориальной распределённостью серверов (по всей России) и сжатыми сроками, в которые необходимо было это сделать.

Дано:

1. Полтора десятка серверов в удалённых локациях. Возьмём за данность, что они имеют интерфейс удалённого управления (DRAC/ILO/IP KVM). Без этого миграция сильно усложняется большим количеством командировок.
2. На серверах крутится по 3 виртуальных машины — контроллер домена, работающий также как DNS и DHCP-сервер (виртуальный диск 40 гигабайт), WSUS + хранилище дистрибутивов (150 гигабайт), и сервер, сканирующий сеть филиала на уязвимости (ещё 40 гигабайт).
3. Промежуточных серверов, на которые можно было бы временно поставить ещё один ESXi и осуществить конвертацию на него «живых» машин у нас нет, но для хранения слитой информации у нас есть файлсервера, подключённые с нашими серверами в тот же свитч — в лучшем случае гигабитный, но чаще всего 100 мегабит.
4. На все сервера у нас есть админские права через AD-группы (в большой компании это не всегда так, но в данном случае мы их получили). Паролей локального админа на эти сервера у нас нет.

Требуется:
Избавиться от связки Windows + VMware Server. Профит: высвобождаем лицензии на ОС, а также ускоряем работу виртуалок, ибо периодически хост-машина сжирала все процессорные ресурсы (причина — процесс tomcat всё того же реликтового гипервизора) — виртуалкам становилось очень неуютно.

Недавно я столкнулся с ситуацией, когда на виртуальном диске в виртуальной машине vSphere начало заканчиваться место, а типичная операция по расширению дискового пространства оказалась невозможной. В моем случае это было связано с интерфейсом подключения диска — IDE.

Статьи, которые можно найти в этой связи в Интернет, например:
VMware Knowledge Base
Аналог, с картинками
к сожалению неполны.

Следование данным статьям приводит к неработоспособности виртуальной машины. После более детальных изысканий, был найден работающий путь, дополняющий вышеуказанные статьи. Для того, чтобы статья предоставляла цельное решение проблемы, здесь будет изложен переработанный и дополненный способ конвертации.

Говорят, что современные аппаратные технологии поддержки виртуализации (VT-d у Intel, IOMMU у AMD) позволяют отдавать физическое устройство на шине PCI в непосредственное управление виртуальной машине. В том числе видеокарту.
Воображение рисует такую конфигурацию: настольный сервер с гипервизором, на нем запускается гостевая пользовательская операционная система, имеющая доступ к необходимым устройствам ввода-вывода, один-два неприхотливых сервера по мере надобности, ну и сколько надо виртуалок для бесчеловечных экспериментов. Управляем гипервизором через консоль в гостевой ОС либо удаленно, с ноутбука, скажем.
Вдохновленный этой картиной, я решил попробовать, но оказалось, что проброс (passthrough) видеоадаптера — задача не совсем тривиальная. Только месяца через три боданий с железом и чтения форумов удалось получить положительный результат. В качестве гипервизора пробовал VMware и Xen. Получилось только с Xen.

В современном мире наверно все адекватные системные администраторы корпоративных сетей используют виртуализацию. Для мелкого и среднего бизнеса одним из самых осмысленных выборов гипервизора является бесплатная версия Citrix XenServer. Основное его преимущество для небольшой фирмы, не имеющей возможности покупать железо под задачи — это огромная гибкость, во многом за счёт Linux, на котором базируется обозначенный гипервизор.

Огромнейшая проблема XenServer, как и Xen Cloud Platform, в очень ограниченном количестве документации. Точнее сказать — в полном её отсутствии для нестандартных ситуаций. В частности нигде в официальных источниках мне не удалось найти инструкции по пробросу блочного устройства непосредственно в виртуальную машину.

Для начала зачем это может понадобиться. Простейший пример — у вас есть сервер без надёжного аппаратного RAID контроллера. Но вы хотите рейд. Без проблем — Linux (и XenServer) содержит великолепнейшую штуку — mdadm. А нужен вам этот RAID для файлопомойки, причём файлопомойка займёт всё доступное место. Смысла городить RAID, а поверх него ещё делать XenServer StorageRepository (SR) с type=lvm, в котором создавать один-единственный диск на весь объём нет. Гораздо лучше создать RAID, и пробросить его блочное устройство непосредственно в виртуальную машину. Так и надёжней — в случае чего вы всегда сможете достать жёсткие диски из сервера и воткнуть их в любую Linux машину, которая тут же увидит все ваши данные.

XEN.org (не путайте с Citrix, использующего гипервизор Xen как основу для своего коммерческого продукта виртуализации ) совместно с Samsung недавно начала работы по портированию своего открытого паравиртуализационного гипервизора на архтектуру ARM v5 и v7.

Участие Samsung в этом проекте неслучайно, все же эта компания один из крупнейших производителей процессоров ARM этих семейств, и ее поддержка для XEN.org будет весьма кстати, тем более, что в компании занимаются вопросами портирования Xen еще с 2008 года.

Сложилось так что понадобился инструмент для управления своими виртуалками вне офиса и при этом не всегда под рукой была машина с ОС Linux. Раньше приходилось активно пользоваться Putty и консольной утилитой virsh, что очень напрягало даже не так управление виртуалками а как их создание. По началу писал bash скрипты для оптимизации своих действий, но не всегда это было удобно.

Тут еще я начал попутно изучать Python, все что было наскриптовано в bash стал переводить в Python. И тогда возникла идея написать веб-интерфейс для управления своими виртуалками в офисе, ну и теми что крутится в личных целях. Так как решались личные потребности, изначально планировалось спрятать такую вещь у себя на веб-сервере, речи о паблике даже в мыслях не было. Но после двух недель интенсивной работы над задачей, когда нарисовался уже почти не большой веб проект, знакомый предложил выложить все это в открытый доступ для чего выделил мне виртуалку под проект.

Я уже описывал в статье «Консолидация CAD-систем» решение, позволяющее обеспечить удаленную работу на профессиональной графической станции через PCoIP. Но эта технология позволяет реализовать подключение 1:1, т.е. один пользователь работает удаленно на одной физической графической станции. Такая реализация подходит под узкий круг задач и не позволяет нескольким пользователям одновременно использовать аппаратные ресурсы графической станции. Для того чтобы обеспечить многопользовательский доступ к одной аппаратной платформе необходимо прибегнуть к виртуализации.
На сегодняшний день существует несколько продуктов, позволяющих использовать в виртуальной машине ресурсы 3D-видеоадаптера. Одни из наиболее популярных решений – это Microsoft RemoteFX, Citrix HDX 3D Professional Graphics, VMware View и Parallels Workstation Extreme.
Инженеры DEPO Computers на протяжении многих месяцев проводят исследование и тестирование этих технологий, оптимизируют настройки, дорабатывают конфигурацию. Основной задачей является виртуализация с эффективным использованием физического графического процессора в виртуальной машине для работы в тяжелых CAD-приложениях. В реализации подобного решения существует две основные трудности: возможность виртуальной машины использовать максимум функционала 3D-видеокарты, и способность протокола передачи данных обеспечить максимум качества и производительности. Технологиям RemoteFX и HDX 3D Pro я планирую посвятить отдельные статьи.
Решение Parallels Workstation Extreme, в отличие от остальных примеров, с помощью PCoIP-карты поддерживает аппаратное сжатие передаваемого по сети потока. В связи с этим оно способно обеспечить наилучший результат по производительности.

На хабрахабре уже неоднократно обсуждались технологии работы с памятью используемые в различных гипервизорах. Эти технологии зачастую принято объединять под общим названием — Memory Overcommitment.
Цели которые обычно стремятся достигнуть применяя memory overcommitment две:

• Повышение утилизации физической памяти хостов преимущественно активными гостевыми страницами памяти на столько на сколько это возможно;
• Повышение общего значение консолидации виртуальных машин.

В этом небольшом топике я хочу предложить вам вскользь вспомнить технологии, которые уже были описаны в значительно большем объеме другими хабра-пользователями, и остановится чуть подробнее на относительно новых, реализованных в гипервизоре vSphere 5.0.

Доброго времени суток, Хабровчане.

Преамбула

XenApp (читается «ЗенАп») придуман компанией Citrix для виртуализации и доставки приложений через тонкий клиент, посредством своего собственного протокола CIA. Надо сказать, что идея сама по себе хороша, потому что в теории избавляет от многих головняков, типа покупки лицензионного софта от Империи Зла и других, чуть менее жадных вендоров. Конечно, это интересно, только если брать приложения в аренду, потому что лицензии на XenApp стоят достаточно дорого. Хочется отметить, что XenApp работает только под Windows.
Не знаю, к сожалению или к счастью, но все крупнейшие производители самого потребляемого софта сейчас имеют свои полнофункциональные продукты, доступные либо через web-интерфейс, либо через тонкий клиент, поэтому мне кажется, что XenApp, как отдельный продукт, очень скоро станет неинтересен конечному потребителю, и останется в поле зрения у компаний, которые сами занимаются арендой приложений. Как раз на аренду приложений сделала ставку моя компания.
И после того, как я был озадачен этой интересной затеей, я понял, что гугль ничего внятного на русском языке про XenApp не выдаёт, а всё, что можно покурить — это обширный мануал на сайте Citrix.com на английском языке. Но разве для нас это проблема?
Руководствуясь чувством «помочь ближнему своему» я решил описать процесс установки и настройки XenApp, который мне пришлось расковыривать самостоятельно, используя англоязычный мануал и плохо знакомого человека, который лицензированный специалист Citrix.

Как вы уже догадались с темы поста речь сегодня пойдет о установке VMware View Client (не VMware View Open Client) с поддержкой PCoIP и поддержкой проброса USB на Linux. Сразу хотел бы предупредить, что данное решение не является официальным, мало того, мне неизвестно насколько оно легально, т.к. в нем используются бинарные пакеты от HP которые официально предназначены для тонких клиентов HP ThinPro. И так, всех, кого не смущает мое предупреждение, прошу под кат.

Появилось желание расширить функционал централизованного хранилища, а счета за электричество натолкнули на мысль о смене железа с Intel Celeron на Atom. Одним из преимуществ можно считать то, что Atom работоспособен даже без активного охлаждения. Таким образом, подверженными механическим поломкам остаются только жесткие диски. В случае, если бы оправдались заявления о проблемах с производительностью, он по-прежнему бы сгодился на FreeNAS хранилище. Итак, тесты:

Данный пост является продолжением Ещё одной архитектуры виртуальной машины (части первой).

В прошлый раз мы остановились на примере модуля, вычисляющего факториал. Рассмотрим его подробнее, а потом запустим и проверим работу.