Как стать автором
Обновить

Комментарии 37

Интересно а что случилось с Hyper-V в ядре Linux?
C компонентами интеграции Hyper-V в ядре Linux все отлично. Вот тут пример их применения

habrahabr.ru/blogs/virtualization/112850/

В принципе любой Linux с ядром начиная с 2.6.32 работает вполне надежно.
Как видите FreeBSD запущенная под Hyper-V работает стабильно и может использоваться для реализации инфраструктурных сервисов, обучения, разработки или тестирования.


Пока видим, что работает. Из чего сделан вывод про «стабильно»?
Любую виртуализированную систему про которую пишу заметки, я оставляю работать на неделю другую и с помощью скриптов прокачиваю через нее гигабайты информации по FTP или SSH.
Хм. Логично. Но, думаю, в таком случае, имеет смысл добавить это предложение где-нибудь в конце статьи.
Добавил. Спасибо за совет.
Зачем эмулировать FreeBSD/Ubuntu/etc. в Windows? Вы реально используете это в продакшне?
На довольно многих предприятиях есть унаследованные инфраструктурные сервисы. Куда либо мигрировать их затратно. Часто люди которые их создавали уже давно уволились. Работает это все на какой либо забытой машине. Никакого резервного копирования не делается.

Если она сломается будет неприятно т.к на этот сервис может быть завязано много бизнес сервисов.

Поэтому мигрировать такую систему в систему виртуализации гораздо выгоднее с точки зрения поддержки и непрерывности бизнеса.

Кластеризацию и резервное копирование виртуализированного сервиса получаем автоматом сразу после помещения виртуальной машины в кластер Hyper-V.
Есть в продакшене, как минимум, две системы под WinSvr и FreeBSD (pfSense) в Hyper-V.
Многие так же запускают FreeNAS под Hyper-V.

Как я понимаб pfSense у вас работает хорошо?

При установке или в процессе экспулатации какие либо неудобства или проблемы были?
Ну известные проблемы, на Hyper-V R1 машина не может погаситься при глобальном шатдауне, либо руками, либо патчить, но с pfSense последний вариант гемморойный.
ЕМНИП решилось засовыванием батника с командой Turnoff в GP->Computer->Shutdown scripts ;)
В R2 есстественно всё ОК.
А с динамическими VHD проблем не было?
Вроде были, не ставилось. Сделали fixed, всё равно там footprint маленький
А зачем?
Например для консолидации систем. Иметь два надежных сервера лучше чем десяток самосборных.

Чем больше элементов тем выше вероятность отказа.

Такие системы легче тиражировать на новые филиалы. Заменять их так же гораздо проще ибо мы отвязаны от физического оборудования.

Прочие полезности вроде резервного копирования, экономии электричества, экономии места в ЦОД тоже вполне применимы.
Если эти два надёжных сервера стоят как десяток «самосборных» — я бы ещё подумал что лучше, потому как чем меньше элементов — тем выше вероятность «крупного» отказа.
Про привязку к оборудованию пожалуй тоже не соглашусь, т.к. этим в основновном страдают системы Win-семейства.

Я конкретно спросил человека — зачем у них в продакшене в виндовой виртуалке крутится БСД-дистрибутив заточенный для использования как фаервол? Почему это нельзя было сделать средствами одной оси и её специализированного софта, например, MS ISA или что там модное сейчас?
Странный вы, а у меня именно _этот_ вопрос спросить?
Ответ простой — когда нужно — ставим RRaS, когда нужно — ставим pfSense, на железе или в виртуалке.
Почему именно pfSense в данном случае — ответ простой: нравится, есть нужный функционал.

А ISA (нынче он TMG) не ставим, по двум простым причинам:
а) в том секторе где мы работаем, на такое решение просто зачастую нет денег, но это менее важно чем вторая причина:
б) даже если есть деньги, нет самого главного: нет _необходимости_ ставить TMG, оно не будет задействовано больше чем просто NAT роутер, а втюхивать такого монстра только ради втюхивания — бессмысленно. Просто нет отдачи с этого.
Если это будет просто NAT — так может, лучше железку поставить? Циску там какую, ну или d-link на худой конец (и еще один такой же д-линк на склад положить — на всякий).
И не надо будет заморачиваться.
Малый бизнес обычно даже на D-link не раскошелится.
Ну, это совсем уж малый бизнес — им не то что виртуализация, им и компьютеры не нужны. Посчитать прибыль с продаж шаурмы можно и на калькуляторе.
Далеко не всё что может делать pfSense, может делать D-Link или даже ASUS WL-5xx перешитый в DD-WRT
Подозреваю, что Cisco ASA может не меньше, если не больше ;)
Не, есть то что АСА не умеет. Например делать связку Squid+HAVP ;)
Дык речь-то шла про «тупой нат», а squid — это уже прокси :)
В том то и плюшки pfSense, можно и проксик, и openvpn, и pptp c radius и ещё кой чего. Плюс веб-гуй, справляются даже мальчики по вызову. Ну и цена ;)
Два надежных + одно хранилище это уже Failover cluster. При наличии Live migration отказ одного из серверов не приведет к остановке сервиса.

А вот с десятком обычных серверов оставка в любом случае будет.

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

В дешевых самосборных серверах скорее всего будет зоопарк устройств.

В случае смерти сервера надо производить переконфигурирование под новое железо.

В случае виртуализации просто скопировать вирт. машину на хост и запустить ее там.
>>В случае виртуализации просто скопировать вирт. машину на хост и запустить ее там.
ВОООТ. Именно.
Не говоря уже о полном бакапе через Windows Backup и иногда улучшения производительности за счёт отвязки от драйверов железа.
Так же быстрый ребут (будь проклят IBM ServeRAID 8, он, сцуко, инициализируется дольше чем у меня запускается сама машина и две виртуалки в ней).
Так же упрощение действий если друг ОС накроется медным тазом из за софтовых причин.
SMB сектор, читай — денег мало.
Плюс консолидация, да, файлсервер + DC даже на самой бюджетной машине не пользуют столько ресурсов, сколько машина может предоставить.
Андрей, в интернете есть разрозненные примеры, как завести дебиан под хайпер-ви, скачав готовое ядро, или собрав свое собственное, но, увы нет никаких отзывов о стабильности. Может, расскажете нам, как оно работает?
Я ставил Debian несколько месяцев назад без компонентов интеграции. Работало вполне нормально.

Если там новое ядро с компонентами то по идее должно быть гораздо быстрее. О том чтобы компоненты работали нестабильно пока ни от кого не слышал.

Может в ближайшее время потестирую и напишу об этом заметку.

Да, у меня в продакшене 2 виртуалки с дебианом, но там до того все туго, что я упираюсь и в сеть, и в диск (причем сам VHD на хранилище себя чувствует замечательно, упираюсь именно внутри).

Буду ждать )
Стоит отметить, что для корректной работы дисковой подсистемы, необходимо использовать диски только фиксированного размера. Иначе, будет падать после установки.
Замечено опытным путём.
Я пробовал проводить установку с динамически расширяемыми VHD. Наткнулся на описываемуб вами ошибку один раз. Ошибка появлялась если во время инсталяции выбрать опцию с установкой портов и пакетов.

Если ставить порты после первой перезагрузки ОС то все работает нормально даже с очень большими динамическими дисками. Или если добавить второй динамический VHD диск уже после установки ОС.
С фиксированными дисками удалось попробовать VHD размером в 127 ГБ.

Надо будет попробовать с помощью dd создать какой либо огромный файл.

Предполагаю что для большинства систем диска в 127 ГБ может хватить.
zfs внутри не пробовали? она динамически расширяться и сужаться умеет, правда диска надо 3 внутри для зрайда, чтобы без особых манипуляций это творить.
К сожалению zfs не пробовал, не знал что ее уже можно применять в реальных системах.

Впрочем добавить виртуальных VHD дисков во FreeBSD не проблема.
Не только можно но и нужно, правда памяти ей надо 1 гб минимум :) (еще попилить настройки надо будет вроде, т.к. она кеширует данные пожестче стандартных фс), рекомендуемое 4 гб.
Зато работает очень шустро и добавляет кучу полезных плюшек, в том числе реданданци в случае с zraid2.
Кстати уменьшать или увеличивать можно и без zraid, я просто не пробовал, потому говорить не буду :).
Но Вы можете попробовать сами, если бсд стоит это делается zpool create (погуглите) и файл какой-нибудь или диск.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.