Установка и настройка Windows Hyper-V Server 2012 R2
Выдалась мне возможность установить и настроить бесплатный гипервизор от Microsoft — Hyper-V Server 2012 R2. Раньше мне приходилось работать с Hyper-V, но в составе полноценного сервера, бесплатную версию я не ставил. В целом, мне нравится Hyper-V, поэтому решил посмотреть на его бесплатную версию. То, что я увидел, немного не совпало с моими ожиданиями, но обо всем по порядку. Данная статья так же подходит для установки и настройки Windows Server 2012 R2 core.
Установка Hyper-V Server 2012 R2
Первым делом скачиваем свежую версию гипервизора с сайта Microsoft. Скачивать нужно обязательно английскую версию. Во-первых, в русской были некоторые баги, хотя их могли и пофиксить уже, но дело не только в этом. Для автоматизации и упрощения настройки Hyper-V Server 2012 R2 мы будем использовать скрипты, написанные для английской версии, в русской они работать не будут. Я сначала поставил русскую версию, потратил какое-то время, потом плюнул и переустановил систему.
Установка достаточно банальна и ничем принципиально не отличается от любой другой установки windows. Скачивается образ, с него загружается система и устанавливается. В конце установки нас встречает консоль с настройками Hyper-V Server 2012 R2:
Сразу же дам подсказку на случай, если вы Hyper-V Server Configuration console закроете. Запустить снова ее можно командой sconfig. Мне пришлось потратить прилично времени, чтобы найти как это сделать без перезагрузки сервера.
Настройка Hyper-V Server 2012 R2
Через консоль задаем необходимые настройки:
1. Указываем рабочую группу. Я рассматриваю вариант настройки отдельно стоящего сервера, не входящего в доменную сеть. В домене настройки будут другие.
2. Указываем имя сервера.
3. Создаем дополнительного пользователя. Можно работать от administrator, который создается по-умолчанию, но лучше создать для управления отдельного пользователя. Позже будет понятно, зачем.
4. Включаем удаленное управление.
5. Включаем автоматическое обновление.
6. Скачиваем и инсталлируем обновления.
7. Разрешаем подключаться по rdp всем клиентам, с любой версией протокола.
8. Задаем сетевые настройки.
9. Устанавливаем время и дату.
На этом первоначальная настройка закончена. Пока все понятно и логично.
А вот что делать дальше я не совсем понял. Я работал со всеми современными гипервизорами: xen, esxi, kvm и всегда все было более ли менее понятно, что делать дальше, но не в этом случае.
Пользоваться командной строкой в windows, по-моему мнению, очень неудобно. Команды длинные, неочевидные, настроить гипервизор и создать виртуальные машины через командную строку невероятно долго и нудно. К тому же копи-паст часто глючит, длиннющие команды приходится набирать вручную. Пришлось гуглить, чтобы хотя бы понять, как мне загрузить образ системы на сервер, чтобы хоть как-то начать установку виртуальной машины.
Подготовка к удаленному управлению Hyper-V Server 2012 R2
Итак, чтобы удобно управлять бесплатным гипервизором Hyper-V Server 2012 R2 необходимо выполнить ряд шагов.
Первым делом берем флешку и записываем на нее Total Commander и HVRemote. Вставляем в сервер и с помощью командной строки создаем на диске С: папку и копируем туда наши программы. Теперь через командную строку запускаем Total Commander:
Теперь у нас есть хотя бы удобный файловый менеджер. Настраиваем дальше. В командной строке отключаем фаервол следующей командой:
Можно его не отключать, а настраивать. Для этого придется вручную консольными командами включать соответствующие правила. Я сначала пошел по этому пути, потом плюнул и просто отключил фаервол. В большинстве случаев в локальной сети в нем нет необходимости. Если же вы хотите оставить фаервол, настроив его, то вот что вам нужно открыть для успешного удаленного управления Hyper-V Server 2012 R2:
Доступ для любых оснасток консоли mmc:
Удаленное управление дисками:
Удаленный запуск оснастки по управлению фаейрволом:
Доступ к расшаренным файлам и папкам:
Использование «Windows Management Instrumentation (WMI)»:
Дальше нам понадобится утилита HVRemote. Запускаем на гипервизоре консоль, идем в папку, где лежит утилита и выполняем команду:
На этом настройка непосредственно бесплатного гипервизора windows для удаленного управления закончена. Он готов к подключению и созданию виртуальных машин. Теперь нам нужно подготовить рабочее место для управления Hyper-V Server 2012 R2.
Удаленное управление Hyper-V Server 2012 R2
Вот тут я столкнулся с очень неприятным моментом. Для удаленного управления необходима операционная система Windows 8 или Windows Server 2012. У меня же основное рабочее место на Windows 7. Я попытался настроить на нем все, что необходимо, но у меня не получилось, поэтому я не буду описывать свои шаги. Возможно есть какое-то рабочее решение, но я не стал тратить много времени на его поиск. Я поступил следующим образом.
Есть бесплатная программа 5nine Manager for Hyper-V. Она позволяет управлять гипервизором Hyper-V Server 2012 R2. К сожалению, бесплатная версия сильно урезана по функционалу и пользоваться только ей для полноценного управления не очень удобно. Но для создания и установки виртуальной машины сойдет. Я ей воспользовался для того, чтобы установить на гипервизор Windows 8.1 и уже на ней настроить рабочее место для удаленного управления гипервизором.
Итак, качаем программу и ставим ее на компьютер. Запускаем и добавляем наш сервер. Указываем в качестве пользователя локального админа гипервизора:
Первым делом в программе нужно настроить сеть, чтобы виртуальная машина имела выход в локалку. Для этого идем в закладку Virtual Network Manager и нажимаем Create. Указываем настройки:
Обязательно ставим галочку Allow management operation system to share this network adapter. Я сначала создал 2 виртуальных соединения на обоих сетевых адаптерах и не поставил эту галку. В итоге сам гипервизор остался без сети. Пришлось очень долго ковыряться и разбираться, как имея только доступ к консоли вернуть все обратно. Оказалось, что это можно сделать с помощью команды:
И еще одно важное замечание. После того, как вы создадите виртуальный адаптер, сетевые настройки физического адаптера, введенные ранее, сбросятся и вы потеряете доступ к серверу по старому адресу. Виртуальный адаптер после создания получает настройки по DHCP. Имейте это ввиду. Если у вас только один сетевой адаптер, то вам необходимо будет на dhcp сервере посмотреть, какой адрес получил гипервизор, и подключаться к нему по этому адресу. Затем вручную менять адрес через консол управления.
Дальше загружаем образ диска с системой через Total Commander и сетевой доступ:
Создаем виртуальную машину. Там все достаточно просто и понятно, делается тыканием мышкой по менюшкам, не буду останавливаться на этом подробно. Если у вас возникает проблема с тем, что 5nine не может подключиться к консоли виртуальной машины и при этом пишет, что невозможно подключиться по rdp, то сделайте следующее. В файле hosts системы пропишите соответствие ip адреса имени сервера и подключитесь к гипервизору по имени, а не по ip. Я один раз столкнулся с такой проблемой.
На выходе имеем Windows 8.1, подключенную к сети. Откываем на ней rdp, подключаемся и начинаем ее готовить для удаленного управления гипервизором Hyper-V Server 2012 R2.
Первым делом создаем там локального пользователя с таким же именем и паролем, как на гипервизоре. Для удобства, работать лучше под этим же пользователем, иначе придется все оснастки постоянно запускать, указывая каждый раз учетную запись администратора гипервизора.
Дальше редактируем файл hosts, добавляем туда точное соответствие имени сервера и адреса:
Теперь установим диспетчер управления Hyper-V. Для этого идем в панель управления, открываем «Программы и компоненты», нажимаем «Включение и отключение компонентов Windows». Загрузится список компонентов, в котором галочкой отмечаем Hyper-V и жмем ОК:
Дальше нам снова понадобится утилита HVRemote. Запускаем cmd в папке с утилитой и выполняем в ней:
Проверяем, все ли у нас нормально настроено:
Все тесты должны быть пройдены.
Добавляем нужные оснастки:
1. Пуск — Все программы — Средства Управления HyperV — Диспетчер Hyper-V
Запускаем его, добавляем наш сервер и управляем им.
2. Запускаем консоль mmc, нажимаем Файл — Добавить или удалить оснастку. Добавляем оснастку «Управление компьютером», выбираем «другим компьютером», указываем hyperv и жмем готово. Потом снова жмем Файл и выбираем «Сохранить как. «. Сохраняем на рабочий стол. Теперь при запуске этой останстки с рабочего стола всегда будет запускаться управление бесплатным гипервизором Hyper-V Server 2012 R2.
Чтобы работала оснастка «Управление дисками», необходимо на гипервизоре запустить службу Virtual Disk и поставить ей автозапуск, чтобы после перезагрузки не пришлось снова ее запускать:
И на самом клиентском компьютере надо что-то открыть на фаерволе, чтобы оснастка заработала, но я его просто выключил. Пока я этого не сделал, «Управление дисками» у меня не загружалось.
С удаленным управлением дисками есть один нюанс. Возможно это только у меня такая ошибка, но я на всякий случай расскажу о ней, может кому-то поможет. Я потратил некоторое время, пока разобрался в чем тут дело. При внесении каких-то изменений в дисках, эти изменения не отображаются. То есть вы что-то сделали, жмете обновить, но ничего не меняется. Но на самом деле изменения произошли, просто их не видно. Чтобы их увидеть, нужно полностью закрыть оснастку «Управление компьютером» и открыть заново.
Теперь можно посмотреть логи системы, расшарить папки, запланировать через планировщик какую-то задачу. В общем, все, что нужно для управления бесплатным гипервизором Microsoft Hyper-V Server 2012 R2 теперь есть в наличии.
К гипервизору можно подключиться по rdp, откроется тот же экран, что и при работе с монитором: консоль управления и командная строка. В ней, кстати, можно запустить диспетчер задач и посмотреть загрузку системы с помощью команды taskmgr:
Из диспетчера задач через File — Run new task можно запускать дополнительные окна cmd или какие-то другие утилиты.
На этом настройка закончена, можно пользоваться. Например, можно установить на hyper-v freebsd, которая теперь имеет полную поддержку в hyper-v.
В таком виде Hyper-V Server 2012 R2 уже вполне удобен в использовании, возможно даже удобнее esxi или xen. Если вам нужно подключить UPS, то рекомендую фирму APC и мою инструкцию по установке и настройке автоматического выключения hyper-v с помощью программы apcupsd.
Помогла статья? Подписывайся на telegram канал автора
Рекомендую полезные материалы по схожей тематике:
Концепция виртуализации сети на базе Windows Server 2012 и System Center 2012 SP1
Доброго времени суток, уважаемые коллеги!
Совсем недавно у нас в Microsoft, в офисе на Крылатском было мероприятие посвященное System Center 2012 SP1, многим новинкам которые появились в сервис-паки были представлены на данном мероприятии. Однако, мы с коллегами проанализировали данные мероприятия, посмотрели что у людей вокруг с SP1 творится и пришли к выводу… что тему виртуализации сетей, концепт этой технологии плохо понятен рядовому системному администратору. Я имею в виду не саму технологию, а как она реализуется в продуктах MS и какие технологии отвечают за виртуализацию сети в Windows Server 2012 и System Center 2012 SP1.
У нас недавно было несколько постов на Хабре на тему виртуализации сети, но мы решили уделить особое внимание этому вопросу, так как тема действительно сложная и критично необходимая.
И так, давайте обо всем по порядку.
Виртуализация сети
Виртуализация сети — это технология, механизм виртуализации который позволяет абстрагироваться от физического уровня работы с сетью до уровня логического, т.е. до уровня программных софтверных механизмов. Также под виртуализацией понимается и типичная консолидация, но здесь она носит немного другой характер. Под консолидацией сети подразумевается возможность создать несколько, множество виртуальных сетей поверх общей телекоммуникационной среды, проще говоря — поверх обычных сетевых адаптеров. Таким образом можно разнести инфраструктуру поверх очень большого количества оборудования. Решение скорее для провайдеров, чем для средних компаний, или для крупных компаний со сложной гетерогенной инфраструктурой.
Однако виртуальные сети — это, конечно, хорошо — но что на счет безопасности? Да и вопросы масштабируемости закрытыми не назовешь такой технологии. И вот для этого в технологиях виртуализации сети присутствует понятие изоляции — простыми словами это механизм, который позволяет работать множеству изолированных сетей поверх общего физического канала таким образом, что ни один канал не знает о существовании друг друга и ведет себя так, как будто он работает поверх собственного выделенного физического канала. Это очень важный момент, поскольку он позволяет реализовывать такие нынче популярные тренды, как BYOIP (Bring Your Own IP) и BYON (Bring Your Own Network) на практике. Эти подходы интересны в первую очередь для провайдеров и представляют собой возможность полностью перенести и сохранить всю сетевую адресацию при миграции инфраструктуры в облако на базе System Center 2012 SP1 и Windows Server 2012 SP1, а второй механизм позволяет также перенести и всю конфигурацию сети за счет ее виртуализации (самой сети и ее компонентов — шлюзов, адресов, виртуальных адаптеров, создание логических коммутаторов и категоризация портов сетевых адаптеров по определенным параметрам и т.п.). Но это уже совсем сложные сценарии, так что пока давайте разберемся с самыми основами, про более сложные вещи погорим с вами в следующих постах на Хабре.
Who is Ху или как-бы понаглядней
Не мудрствуя лукаво, перед тем как рассказывать про всякие там элементы инфраструктуры и дабы не вгонять читателя в больший конфуз, предлагаю в начале ознакомиться с принципиальной схемы устройства компонентов сети с точки зрения вопросов виртуализации сети и возможностей Windows Server 2012 и System Center 2012 SP1.
Рисунок 1. Принципиальная схема виртуализации сети
Я специально не стал убирать англоязычные названия, так как многим они пригодятся в работе с WS и SC. Ну а перевод прилагается — так что все понятно. Ну и глядя на схему, давайте кратко опишем принцип работы такой сети, начиная с физического уровня и заканчивая уровнем клиентов (в данном случае это уровень ВМ). На самом низком уровне, как оно и положено, находится физическая есть, сама среда передачи данных, аппаратная инфраструктура, физические каналы, железо, сеть — называйте как хотите.
Дальше у нас с вами есть хосты виртуализации Hyper-V и они у нас включают в себя два важных элемента — логические коммутаторы (logical switches) и профили Uplink-порта на физическом сетевом адаптере. То есть хост Hyper-V представляет собой интерфейс для доступа к физической среде — с одной стороны, виртуализацию сети и предоставление интерфейса для ВМ — с другой. Поскольку логический коммутатор представляет с собой набор виртуальных коммутаторов Hyper-V с идентичными настройками то мы можем с вами говорить о том, что логические коммутаторы в совокупности представляют собой логическую сеть (logical network). По логике вещей конфигурация из логических коммутаторов составляющее логическую сеть можно классифицировать как сайт (site) — единое непрерывное сетевое пространство.
А вот дальше, уже, на уровень выше, у нас с вами начинается уже непосредственно виртуализация сети (даже лучше «сетей»). Следующий уровень — Сеть ВМ. Сеть виртуальных машин представляет собой следующий уровень виртуализации уже именно сетей — поскольку сети виртуальных машин, как уровень виртуализации, способны к изоляции собственной инфраструктуры, то есть именно этот слой позволяет создавать нам виртуальные изолированные сети, которые не имеют доступа друг к другу — фактически каждая сеть воспринимает себя как единственно-физическую в своем окружении.
Поверх сетей у нас находятся виртуальные машины, а общаются они с сетью средствами виртуального сетевого адаптера. Собственно говоря с точки зрения вопросов управления и развертывания (System Center 2012 VMM SP1) — есть профили портов и они применяются поверх сетевых адаптеров виртуальных машин, задавая им необходимые сетевые настройки.
Это если вкратце как оно работает — теперь давайте подробней посмотрим какие новшества в VMM 2012 SP1 помогают нам в работе.
Компоненты VMM
Теперь давайте рассмотрим компоненты VMM 2012 SP1 с точки зрения всего вышесказанного.
Итак, в порядке появления в VMM:
1) Логические сети (logical networks) — в контексте VMM, логическая сеть это необходимое условие для дальнейшего создания сетей ВМ, то есть механизм который использует виртуализацию сети хостов и представляет его как единое непрерывное сетевое пространство, поверх которого можно «нарезать» виртуальные изолированные сети. Этот объект мы создаем всегда в первую очередь, когда говорим о виртуализации сети в VMM 2012 SP1.
Рисунок 2. Логические сети в VMM 2012 SP1
Сам по себе механизм виртуализации сети заложен в Windows Server 2012 — и по сему 12-ый сервер — единственная ОС от MS которая позволяет реализовать виртуализацию сети без пресловутого метода VLAN’ов, но также позволяет использовать данный метод самим конечным пользователям внутри их виртуальной сети. Сама фишка поддерживается на уровне драйвера сетевого адаптера — поэтому не забудете его активировать на самом физическом адаптере, поверх которого вы будете назначать виртуальный коммутатор.
Рисунок 3. Активация драйвера сетевой фильтрации для виртуализации в Windows Server 2012
Далее мы как раз-таки и создаем саму логическую сеть — а после нехитрых манипуляций с драйвером мы можем использовать и виртуализацию сетей для их изоляции.
Рисунок 4. Создание логической сети с возможностью последующего создания изолированных сетей ВМ
2) В простейшей конфигурации для реализации виртуализации сетей все, что было бы необходимым сделать для «нарезания» бесконечного числа (образно) изолированных сеток — это воздание сети ВМ (VM Networks). Это по сути объект логической сети которая строится поверх логической сети и предоставляется как инфраструктура сети для обмена данными между ВМ. B вот теперь мы можем создавать изолированные виртуальные сети (сети ВМ) для выделенных изолированных инфраструктур.
Рисунок 5. Создание сетей ВМ в SC VMM 2012 SP1
Как вы видите, изоляция распространяется на адреса IPv4 и IPv6 выборочно или же единовременно. Также есть возможность создать сеть без изоляции — в этом случае область сети ВМ будет совпадать с областью логической сети — такие конфигурации сетей ВМ используют с целью предоставление доступа к объектам инфраструктуры VMM и частного облака.
3) Далее в VMM мы с вами встретим еще один интересный компонент — это пулы MAC-адресов (MAC Address Pool). Данный механизм интересен с точки зрения управления и развертывания инфраструктурой. Проще гововря — у каждого производителя оборудования есть свой пул MAC-адресов, которые они назначают своим устройствам. Поскольку в пределах одного вендора оборудования, как правило, используются схожие драйвера и компоненты — это позволяет автоматизировать задачи развертывания кластеров Hyper-V с нуля, включая необходимые компоненты для категории серверов. Допустим, у нас есть 3 вендора оборудования: Dell, IBM и HP.
Рисунок 6. Пулы MAC-адресов
Мы можем подготовить свои образы развертывания для каждой группы серверов, тем самым исключив вероятность дисконфигурации хоста, а благодаря MAC-адресам мы гарантируем соответствие образа с нужными драйверами и компонентами с оборудованием, на которое они разворачиваются.
4) Дальше в VMM у нас присутствует такой элемент, как балансировщики нагрузки (load balancers) — это могут быть как аппаратные, так и виртуальные элементы инфраструктуры, которые позволяют обеспечивать как отказоустойчивую, так и увеличенную полосу пропускания к необходимому сервису, который запущен на виртуальных машинах. Иными словами — привычный балансировщик. По умолчанию поддерживает работу с Microsoft NLB (а кто бы сомневался!?), но поддержка сторонних балансировщиков осуществлена через провайдер — допустим, вы можете поставить Citrix NetScaler и использовать его. Только помните — прежде чем использовать балансировщик — вы должны установить провайдер для работы с ним на сервере VMM и перезапустить его службу (VMM). Также вам понадобятся реквизиты доступа к вашему балансировщику.
Рисунок 7. Регистрация баласнировщика Citrix NetScaler
5) Сам по себе балансировщик — штука полезная, но в данном случае неэффективная. А вот если мы будем использовать профили VIP (Virtual IP) — виртуальных IP-адресов в сочетании с балансировщиками и задействуем их при развертывании и масштабирования наших сервисов — инструмент отличный. Иными словами профиль VIP — это виртуальный IP-адрес, который получает ваш сервис при развертывании из шаблона VMM. Этот адрес скрывает под собой все компоненты инфраструктуры сервиса (web-сервера, СУБД и прочие) и позволяет таким образом внутри сервиса организовать ферму и кластер для решения вопросов доступности и масштабируемости, ведь при развертывании сервиса из шаблона и использовании балансировщиков с VIP-профилями мы можем на лету создавать необходимые компоненты сервиса (в виде ВМ) — и сразу же добавлять их в общий пул для работы, а поскольку VIP-шаблон производит по сути виртуализацию IP-адреса внешней среды — того канала, откуда пользователи получают услугу.
6) Перед тем как подробнее говорить про логические коммутаторы (logical switches), давайте посмотрим на одну картинку ниже:
Рисунок 8. Требования для создания логического коммутатора в VMM
Из того, что мы видим следует то, что просто так создать логический коммутатор нам никто не даст — есть ряд некоторых условий:
a) Сначала нам необходимо создать логическую сеть и сети ВМ — ну с этим мы уже разобрались.
б) Дальше нам необходимо понимать, будем ли мы использовать расширения виртуального коммутатора Hyper-V из Windows Server 2012 — и если да, то нам нужно необходимо зарегистрировать провайдер в VMM для работы с ними. Здесь речь идет именно о механизмах расширенных возможностей коммутатора — фильтрация трафика или же дополнительных возможностей за счет сторонних дополнений.
в) Если же мы не планируем использовать прошлый сценарий ни на базе WS2012, ни на базе сторонних решений интеллектуального перенаправления, то нам не остается ничего другого, кроме как создать профили нативных портов (native port profiles) и портов для виртуальных машин для дальнейшего их сопоставления друг другу. Данный механизм фактически предъявляет требования по настройкам именно драйвера сетевого адаптера и сопоставления требований с фактическими возможностями драйвера. Иными словами мы можем логически разделить трафик по его типу (служебный, коммуникационный, SAN-трафик и прочие его типы) и применять эти настройки с точки зрения сети как механизм сопоставления настроек и поведения адаптеров хостов Hyper-V, который подключены к нему (физические адаптеры) с профилями портов виртуальных адаптеров внутри ВМ. Иными словами это механизм который с одной стороны разделяет логически трафик от комутатора до хоста, назначает физическим адаптерам определенную кофигурацию для обработки того или иного типа трафика, а на виртуальных машинах этот же механизм используется для определения свойств виртуальных адаптеров внутри ВМ, чтобы сопоставить их со свойствами адаптеров хоста — как крезультат — автоматическое назначение портов.
Рисунок 9. Создания профиля типа uplink
Как вы видите, при создании профиля нативного порта вы можете выбрать тип профиля, и собственно область его действия. Uplink — для применения на сетевые адаптеры, которые обеспечивают работу виртуального коммутатора, а профили виртуальных адаптеров — собственно работают на уровне адаптеров виртуальных машин. Область действия профиля же назначается на уровне логической сети.
И вот тут наступает самый интересный и связующий момент. Есть еще один компонент — классификация портов (Port Classification) — это собственно говоря, механизм для группирования профилей нативных портов. То есть вы создаете различные профили портов, допустим с низкой скоростью, но для разного типа трафика — и объединяете дальше эти порты в классификацию «Slow». И когда вы создаете логический коммутатор, вы указываете сразу в нем канал для выхода во вне (uplink) и задаете сразу классификации портов, включая все необходимые профили. Так как профиль распространяется на логическую сеть, то область его действия определяет и область действия логического коммутатора. Классификации портов также применяются при создании облака в VMM.
7) И последний механизм-компонент в VMM — это шлюзы (gateways). Шлюзы, как ясно из их названия, предназначены соединять между собой разрозненные и изолированные сети в единую непрерывную сеть. Иначе говоря, это механизмы удаленного доступа и взаимодействия на уровне сетей и их границ. Компонент шлюзов в VMM также использует сторонние инструменты и провайдеры для работы со шлюзами. Шлюзы могут быть как аппаратные так и программные. Шлюзы также могут использовать механизмы VPN для обеспечения своей деятельности. Также шлюзы позволяют использовать сценарии гибридного облака при создании гибридной сети Windows Azure VM. А если проще и по основному — то вы можете с помощью шлюзов соединять между собой виртуальные изолированные сети или же виртуальные сети с внешними сетями клиентов с помощью привычных для них инструментов (ну это если железо идентичное либо с функционалом и механизмами взаимодействия).
Ну что же, уважаемые коллеги!
На этом рассказ про концепцию виртуализации сетей окончен, но только на сегодня.
В дальнейшем я планирую рассказать про более сложные сценарии и варианты использования всех этих и сторонних компонентов в комплексе.
Так что следите за новостями и держите руку на пульсе!
С уважением,
человек-огонь
Георгий А. Гаджиев
Эксперт по информационной инфраструктуре
Microsoft Corporation