Мне кажется, автор слегка неверно интерпретировал это объявление. Это всего лишь возможность для партнёров, которые предоставляют облачные рабочие места, прозрачно лицензировать Windows 10 Enterprise в облаке для своих клиентов. Это предложение интересно исключительно этим партнёрам и их клиентам (малому бизнесу без своего штата IT).
Корпоративных клиентов (от 500 рабочих мест) это предложение не интересует, они давно сидят на Enterprise Agreement, платят в месяц, как правило,
Если я ничего нее путаю, лет 5-10 назад с этой страницей играло пол интернета, тогда без всяких спецсимволов можно было URL собрать. Видимо, тогда это «починили» вставив проверку на наличие некого спецсимвола.
Думаю да, если учесть вот эти даты, то статистика ещё хорошая относительно:
— 8 апреля 2014 (EOL Windows XP);
— 14 июля 2015 (EOL Windows Server 2003);
— апрель 2014 (NIST объявил SSL и TLS<1.1 небезопасными, что автоматически означает попадание в статистику всех серверов, поддерживающих TLS<1.1, в частности, всех IIS на Windows 2008 R1 и всех современных серверов, в которых владельцы решили оставить возможность соединения по SSL/TLS1.0 (при TLS 1.2 по умолчанию) для совместимости с WinXP или старым Android).
Это называется «слышал звон да не знаю, где он». Весь MitM там был (уже и это пофикшено) в сообщении программе, что уже есть новая версия, за которой она пошлёт пользователя вручную её скачивать с официального вебсайта. О, да — это, конечно же, «незащищенный канал связи с внешним миром до ноутбука администратора»!
Про «эксплойты и трояны, заточенные под него, которые успешно вскрывают базы Keepass», это, конечно, про единственный PoC KeeFarce, который перехватывает расшифрованную базу из памяти, если компьютер администратора уже заражён.
Да, вектор атаки есть такой, но он один и достаточно сложный — нужен полный доступ к компьютеру админа.
А вот перечислять векторы атаки на Thycotic можно очень долго: это все атаки на IIS, атаки на ASP.NET код самого Thycotic, атаки на Windows на веб-сервере, атаки на компьютеры пользователей, включая браузер, фишинг и реальный MitM (прокси-сервер с доверенным корневым сертификатом и т.д.)…
С сервера (или из резервной копии) нужно украсть один файлик — «encryption.config», после чего можно идти читать всю базу без всяких DLL injection. Мастер-пароль KeePass хотя бы не хранится в файле на диске.
Охранять сервер с Thycotic нужно как зеницу ока, при этом к нему должны иметь доступ множество людей (или заводить отдельный сервер для каждого уровня доступа?). «Главный» админ (или админы) всё равно всё сможет прочитать в обход всех журналов аудита, вытянув encryption.config и базу не с прода, так из бэкапа. Если сервер в AD, то все, кто могут на него полиси поставить, опять же, могут получить encryption.config. Резервные копии сервера нужно делать? Тот, кто к ним имеет доступ и может их расшифровать, будет иметь все пароли. Админ WSUS? Не проблема сделать ручной пакет обновлений. Даже админ антивируса, в некоторых случаях, может, наверное, как-то заставить антивирус файлик этот взять «для анализа». Все эти люди в случае KeePass не будут иметь доступа — пусть даже они смогут украсть .kbdx — он зашифрован, ключ им неизвестен.
Остаются админы филиалов и прочие, которые доступа к центральной инфраструктуре не имеют? Им хватит AD/RADIUS/TACACS, зачем изобретать велосипед?
При этом нам надо дать полнейшие права серверу Thycotic на полный доступ ко всей абсолютно инфраструктуре. Если даже в конторе 2 человека всего IT: сисадмин и сетевой админ, и то ни у одного из них не будет такого доступа, который требуется Thycotic. В больших организациях такой доступ из одной точки вовсе немыслим.
В конце концов, в случае катастрофы в инфраструктуре админам останется только сидеть и кусать локти, если доступа к северу Thycotic нет.
Но для проверок всё очень красиво с Thycotic — логи аудита, ролевой доступ, автоматическая ротация паролей — аудиторы и менеджеры будут в восторге. А кому надо — все пароли получат без всяких записей в логи.
Да, если никогда не пользоваться инструментом Security Filtering, то политики работают. Именно поэтому, по всей видимости, ни разработчики обновления, ни тестировщики (если они ещё остались) не заметили на тестовом localhost никакой проблемы и выпустили, мягко говоря, проблемное обновление изначально даже без приписки об изменении поведения групповых политик.
— Доктор, когда я делаю вот так, у меня вот тут болит!
— А вы вот так не делайте!
И под «руками» я имел в виду "ручное редактирование списка контроля доступа на закладке Security в свойствах политики в режиме её редактирования". Использование инструмента Security Filtering на первой странице Group Policy Editor я бы не стал называть ручным редактированием: он даёт упрощённую и наглядную картину. И как бы мы не называли использование инструмента Security Filtering, работать этот инструмент после применения обновления перестаёт.
Если честно, то мне кажется, мы ходим по кругу. Создайте тестовую политику и посмотрите, чем отличается инструмент GPEdit Security Filtering от редактирования списка контроля доступа (закладка Security в свойствах политики).
Особенный контраст вы заметите, если между вашей рабочей станцией и контроллером домена будет хотя бы 10-20ms пинга, но это так, дополнительный «бонус», в статье не про это речь.
Всё верно — GPO будет работать после добавления руками Authenticated Users или Domain Computers с правами read в список контроля доступа каждый раз после того, как вы попытаетесь воспользоваться security filtering. Изменение схемы нужно для того, чтобы избежать необходимости производить эти действия руками каждый раз.
Возможно, вы путаете инструмент Security Filtering (изображён на скриншоте «Список фильтров безопасности (security filtering)» в статье) и закладку Security при редактировании политики? Это разные (хоть и связанные) инструменты. Ручное редактирование в закладке Security будет работать, если вы всю оставшуюся жизнь будете помнить, что там теперь нельзя убирать read для Authenticated Users (не заменив его Domain Computers).
Вот по шагам поведение после установки обновления и без применения инструкции:
1. Создаём тестовую политику с правами по умолчанию.
2. Заходим в Security Filtering на первой странице политики.
2.1. Добавляем группу, к которой политика должна применяться.
2.2. Удаляем Authenticated Users (автоматически удаляется и read и apply!).
3. В случае user scope политики получаем ошибку применения, если установлено обновление.
4. Руками добавляем Domain Computers/Authenticated Users в Security.
5. Только после этого политика начинает работать.
Вопрос — зачем теперь нужен secuirty filtering, если нам надо потом руками лезть в список контроля доступа?
Приведённая инструкция возвращает нормальное поведение security filtering: убираем authenticated users, добавляем нужную группу — всё сразу работает.
Я это всё подробно рассмотрел в статье, пожалуйста, прочтите внимательно.
Ещё раз в двух словах: «решение» AD DS Team предполагает фактически отказ от использования Security Filtering и необходимость помнить это «решение» как «Отче наш» при каждом создании/изменении политик.
Предложенное изменение схемы AD делает только одну вещь: автоматизирует то же действие, которое предписывается делать каждый раз руками, следуя «решению» AD DS Team.
Более того, я целый абзац «Предупреждение» посвятил альтернативе для тех, кто не готов изменять схему.
Поведение политик не менялось 16 лет, и, если Microsoft вдруг захочется изменить его ещё раз, то всем, вне зависимости от того, следовали они этой статье или нет, придётся снова что-то менять.
Отменить предложенное изменение схемы можно в любой момент, убрав SDDL-вставку так же, как она была добавлена. Даже если это сделать спустя много лет, результат будет 100% тот же, как если бы все эти годы администратор вручную следовал решению AD DS Team, добавляя Domain Computers в новые политики. Никаких других изменений не предлагается.
Я бы, наверное, порекомендовал последовать инструкции, даже если сейчас не применяется фильтрация: обновление ломает инструмент фильтрации, без изменения схемы нельзя будет им пользоваться. Когда возникнет необходимость фильтрации, нужно будет вручную редактировать список доступа.
Вы правильно описали универсального (пост-)советского инженера. Мне кажется, такие специалисты достаточно редки даже в ваших краях, не говоря уже о моей стороне глобуса, где предпочитают специализацию. Они ценны на этапе проектирования и создания инфраструктуры, но на этапе поддержки и планового развития в них уже нет необходимости. Такие специалисты достаточно дороги, чтобы держать их просто для поддержки, если вы не интегратор. Вот тут на сцену и выходит условный младший инженер в пост-советской терминологии (или Server technician/associate, не путать с Desktop technician, который как раз техник). В общем, не важно как он называется, но вероятность того, что он сможет, скажем, посмотреть Events на Hyper-V сервере, достаточно высока, а для VMware уже нужно нанимать специалиста по VMware.
1. Собственно, драйвера без подписи WHQL, и, соответственно, без тестирования WHC просто нельзя установить на 64-битных Windows Server. Я понимаю, что вы хотите сказать, но, мне кажется, что это из разряда «зелен виноград».
2. Вы можете для себя, конечно, устанавливать сколь угодно мягкие рамки, но стандарты индустрии, например, §6.2 PCI DSS требуют установки обновлений безопасности на критические системы максимум в течение месяца, на остальные — трёх. Коммутаторы и прочее сетевое оборудование входит в список систем, подлежащих обновлению. Даже если вашей компании не требуется формальная сертификация, прислушиваться к стандартам, мне кажется, всё равно стоит.
3. Если задача — работать строго с системой виртуализации, не пересекаясь ни с какими другими подсистемами, специализируясь только в этой узкой области, изучая только её, то, возможно, одна программа-агрегатор удобнее. Если же виртуализация — просто ещё один инструмент в руках системного администратора, то чем повторять в отдельной консоли все функции, которые уже есть в других, имеет смысл просто добавить недостающие. Hyper-V — всего лишь ещё одна роль Windows Server, SCVMM — ещё один компонент SC.
Более того, решение задач настройки Windows Server всё больше дрейфует в сторону единой консоли, имя которой — PowerShell.
5. Ок, принимаю к сведению ваши наблюдения. Единственное, я не уверен, что вы не путаете поставку в виде универсального OVF с отсутствием поддержки/невозможностью запуска под Hyper-V. Приведу пример: OSSIM. Формально (как минимум раньше, сейчас может уже записали «поддержку»), был ISO образ для установки на голое железо или на VMware. Реально — всё работало под Hyper-V даже со старым ядром, включая анализ копии сетевого трафика. Поддержки в смысле службы поддержки нет ни под VMware ни под Hyper-V — OpenSource.
6. Я не разделяю ваше понимание, HNV — полная виртуализация, всё заворачивается в NVGRE (а в новой версии, и, опционально, в VXLAN). За что VMware просит столько денег при наличии конкурирующих бесплатных (или более дешёвых, в случае SCVMM) решений — мне лично непонятно.
«А вообще просто лично меня задели сильно эти изменения, простите, не удержался. Кстати, S2D будет только в старшей редакции.»
Я тоже не в восторге от этого изменения политики лицензирования Windows, но эта проблема одинаково коснётся пользователей всех систем виртуализации. Что до S2D, я поначалу тоже стал проклинать маркетологов, но потом подумал, что при реальном внедрении там и так уже будет Datacenter для виртуальных машин в большинстве случаев. Хотя, всё равно обидно, да.
«И хочу сказать, что и за vmware, и за Hyper-V есть аргументы. Иначе, наверное, vmware бы уже прекратила существование.»
В наш век маркетинга как раз более продвинутые, на мой взгляд, BlackBerry OS 10 и Windows на мобильниках прекращают своё существование, а покупатели стоят в очередях за очередным iPhone и Galaxy S7.
У VMware более удачная политика продвижения, они на рынке дольше и у всех на слуху, как ксерокс фирмы Xerox. Немалую роль играет и, в моём понимании, не очень честный подход со стороны сертифицированных VMware системных администраторов: они вложили немалые деньги в своё обучение и сертификацию, плюс боятся конкуренции с обычными администраторами Windows, так как никаких arcane знаний администрирование Hyper-V не требует. Поскольку начальство/заказчик всё равно не могут сделать осознанный выбор, решение использовать ту или иную платформу полностью отдаётся на откуп системным администраторам, а те необъективны в своём выборе, и, для сохранения своих инвестиций и защиты рабочего места, покупают (на деньги заказчика/работодателя!) дорогостоящую систему от VMware при наличии однозначно не худшей бесплатной альтернативы от Microsoft.
Я также читал, что VMware платит интеграторам просто за факт предложения VMware в новых проектах, но это, возможно, FUD — не поручусь.
Пока я насобирал следующий список преимуществ (без кавычек) VMware:
— vSAN (хотелось бы ещё увидеть статистику реальных внедрений, ведь необходимо совсем другое оборудование, чем для классической виртуализации), который появился относительно недавно и через пару месяцев получит конкурента в виде S2D.
— Какие-то проприетарные виртуальные appliances. Опять же — совсем нишевый случай.
То есть абсолютное большинство инсталляций VMware последних лет не имели под собой никакого фактического обоснования.
Решения на базе Hyper-V я внедряю где-то с конца 2009 года, то есть примерно с выхода 2008R2. С VMware ESX/ESXi работал с версиями 2-4. Как я уже писал, со времён выхода Hyper-V 2008R2 я не вижу смысла при прочих равных в использовании VMware, потому и задаю вопросы тем, кто остался на VMware, как оно там.
«Но также я ненавижу настроенный Windows: обязательно где-то забудешь снять/поставить галочку и система будет себя вести непредсказуемо, пока не найдёшь искомую галочку.»
Или я вас неправильно понимаю, или вы неправильно «готовите» Windows Server: для того и существуют GPO, SCCfgMgr и прочие Desired State Configuration, чтобы по возможности никогда не лезть в настройки продакшена руками. В крайнем случае, идёт запись всех действий в систему контроля изменений с последующим превращением записи в CMS в пошаговую инструкцию. Искать каждый раз галочку, это, конечно, олдскульно, но, мне кажется, так давно не стоит делать.
Что до поддержки двух систем в одной организации, это мне кажется странной идеей: правильное разделение основных и резервных мощностей, production и staging требует как раз унификации, а не различия между платформами. В то же время, поддержка двух платформ в дополнение ко всем вышеперечисленным разделам приведёт к дикому раздутию штата и бюджета IT, а на дворе кризис, бизнес впервые начал считать деньги. И, главное, я не вижу как именно фирма-поставщик виртуализации (не, скажем, одновременное обновление, а именно марка системы) может быть той SPoF, которой следует избегать любой ценой.
Навыки настройки файлового сервера помогут самым прямым образом — вместо всех этих LUN, если нет унаследованного SAN, сейчас (года с 2012-2013) имеет смысл развёртывать SoFS (тот самый «файловый сервер на Win») с SMB3 для хранения виртуалок. Multipath, bandwidth trunking, всё в лучшем виде. (Кстати, в ESXi поддержка NFS 4.1, насколько я знаю, появилась год назад и с такой кучей ограничений, что даже фанаты плюются).
И навыки администрирования AD/GPO пригодятся, и PowerShell, и mmc, и подсистема Event-ов, включая возможность централизованного сбора, и Failover Cluster Manager, и Windows Firewall с IPSEC, и Performance Monitor и другие средства мониторинга — это просто Windows Server с полутора ролями. Человек со знанием Windows Server сможет администрировать Hyper-V сервера значительно за пределами «GUI, где всё подписано».
Не удержусь, прокомментирую по пунктам, хоть, простите, в отличие от автора статьи, ваше сообщение — уже на грани холивара.
1. «Отсутствие драйверов — это благо!», «Мир — это война!», «Свобода — это рабство!»…
2. Отказ от установки обновлений как-то странно обсуждать даже. Ваше право, но это уже давно плохая практика. Даже если своего понимания нет, почему так не стоит делать, аудиторы не дадут. Для чего в кластере cattle молиться на аптайм — не представляю. Cluster-aware update те немногие обновления, которые нужны Hyper-V, заливает сам по очереди на все ноды.
3. Эффект утёнка? Стандартный стиль mmc, всё в общей парадигме Windows Server management.
4. Windows Server SA (который, по хорошему, и так должен быть у всех, при наличии виртуальных машин с Windows Server) даёт право на поддержку, не premier, но и не Technet. Premier это, по сути, замена штатной единице, стоит соответственно. Покупать ли поддержку у Microsoft — ваш выбор. Пользователей VMware никто не спрашивает.
5. Можно статистику в качестве пруфа или пояснение термина «основной»? OVF вообще как бы независимый стандарт для обмена, MVMC его импортирует.
6. С vSAN соглашусь — свою специфическую нишу решение имеет. S2D, действительно, выйдет через пару месяцев.
Что до NSX, я, может, что-то пропустил, но vCloud Networking and Security (ныне NSX) догнал SCVMM 2012 SP1 (в котором уже была технология SDN) только в 2013 году. Это не то что не «VMware-only технология», тут VMware в догоняющих. Более того, при цене одной лишь NSX, насколько я знаю, «от $5k за процессор», нужно ещё поискать того, кто её в здравом уме купит.
7. Насколько «красивее» чужеродная в среде Windows-серверов технология «сама-в-себе» лучше спросить у стандартного Windows-админа, которому вместо привычных систем достаётся в наследство такое чудо. Вон ниже в треде человек перепутал HA и FT, и немудрено.
Представлять же благом отсутствие интеграции с централизованной аутентификацией, менеджментом и мониторингом (для которых, внезапно, необходимы сервера аутентификации AD), замена привычных средств (mmc, WMI, PowerShell и т.д.) самоделками — это продолжение вашего пункта 1: «Любовь — это ненависть!»
«Хотя, с введением per-core licensing в WS2016 и возвращением функциональных отличий в редакциях всё может вдруг стать не так однозначно…»
Почему все VMware-админы приплетают к Hyper-V лицензирование Windows Server (как будто в середе VMware можно их не лицензировать!), для меня загадка. Видимо, все VMware-ресурсы друг у друга таблички перерисовывают без понимания, а вы потом их читаете, не разбираясь. Повторю ещё раз: Hyper-V — бесплатный гипервизор.
«P.S. А вот с FUDом по поводу нежелания переводить рабочие системы резко на новейший Win Server вы точно погорячились.»
Простите, вы перевираете. FUD-ом я назвал FUD про «проблемы ОС».
«Кто в здравом уме будет грабли собирать на боевых нагрузках? Тем более, когда речь об ОС — в этом случае и железо тоже должно быть совместимо. А вендоры еще не собрали баги в новых драйверах… Чур меня, чур! Год минимум от релиза. В лабе погонять — другое дело конечно, там и с technical preview начинать можно.»
Я так и написал — хотите консервативный подход — был (в 2012) Hyper-V Server 2008R2, который уже 3 года был в продакшене. Когда дозреете для апгрейда — гипервизор бесплатный, покупать новую версию не надо.
А если «год минимум до релиза», то автору нельзя было и ESXi 5.0 ставить — ей тогда года не было.
Предлагаю отойти от риторики холиваров и, если хотите, продолжить более предметно, а не «нравится — не нравится».
Из всех ваших пунктов я себе на заметку могу взять лишь vSAN. В условиях миниатюризации и всё большей специализации вычислительных нод я не уверен, что за гиперконвергентностью светлое будущее, но согласен, что наличие функциональности — это плюс. Для кого-то, возможно, это станет решающим фактором. Через несколько месяцев и в этом вопросе будет достигнут паритет.
Спасибо за интересное продолжение диалога!
Сразу оговорюсь, это не холивар, мне интересно сравнить впечатления и обменяться опытом. Я не «не люблю VMware» (как вы со смайликом написали в другом комментарии), я не вижу смысла его использовать при прочих равных, потому мне интересно услышать от тех, кто его всё-таки выбрал, о причинах — что я пропустил?
По пунктам:
1. Ну, то есть, фактически, вариант выключения питания. Да, красиво, на всех демо-стендах именно его и показывают. Практика, однако, даже моя личная, говорит скорее о возможности выхода из строя материнской платы, памяти, контроллера хранения с ненулевой вероятностью silent corruption данных в момент, предшествующий окончательному выходу из строя. В некоторых случаях приходится вообще откатывать данные из архива/снэпшота, при возможности, проводить ручную проверку, слияние последних данных и архивной копии и т.д. Продолжить выполнять задачу на другой ноде как ни в чём не бывало в таком случае — однозначное зло. Даже если мы примем, что вероятность «атомарной» поломки выше, чем пролонгированной с периодом silent corruption, вероятность последнего варианта ведь не 0. В таком случае, стоит очень хорошо подумать с точки зрения менеджмента рисков, что хуже — пару минут downtime или повышение вероятности повреждения данных.
Сразу прокомментирую и соседнюю ветку:
" Вы не считаете, что отказоустойчивость нод кластера для важных систем — это хорошо? Понятное дело, что стоит вопрос в реализации… Но всё же? "
Я уже писал выше — отказоустойчивость для важных систем должна достигаться на уровне приложения: active-active, транзакции, проверка целостности данных. Если этого нет, значит данные не такие уж и важные. Отказоустойчивость именно *нод* кластера — это подход pet (vs. cattle), он себя изжил, а в данном случае, с точки зрения менеджмента рисков — мы увеличиваем риски, внедряя VMware FT.
2. Так и Windows Server с ролью Hyper-V не требует покупки дополнительной лицензии, если у вас хоть одна виртуалка с Windows Server внутри лицензирована. Вас кто-то ввёл в заблуждение, нет за это оплаты и в таком случае. Есть платный SystemCenter, но это совсем другой продукт, виртуализация там — лишь один из компонентов.
3. Мне кажется, тут никаких вариантов кроме сесть на телефон и не слезать с гарантийной поддержки до полного исправления ситуации просто нет. Если прошивка контроллеров заведомо дефектная, ставить такие контроллеры в продакшен на основании того, что после загрузки они пока ни разу не глючили — неверно.
И, опять же, менеджмент рисков говорит, что нода, которая не загрузилась (она не под нагрузкой, есть ещё 4 других и вторая площадка) представляет меньшую опасность, чем внезапное повреждение системного раздела под полной нагрузкой и, в лучшем случае, выход из строя ноды в случайный момент (вероятно, под нагрузкой), а в худшем — опять же, повреждением данных.
4. Про FT — выше. Как инженер, мне кажется, вы должны были не только в FUD-таблички вроде этой смотреть. В ней, между прочим, к каждой второй строчке надо добавить сноску, плюс там нет ни одной строчки с функциональностью, которая лучше в Hyper-V (если совсем нельзя было пропустить, сделана обобщающая строчка, а в ней через запятую указана в том числе киллер-фича Hyper-V, так что и непонятно, это вообще плюс, минус или просто другое название).
И вы, простите, продолжаете, верю что неосознанно, идти по методичке. Следующий стандартный пункт — «поддержка ОС». «Free as in 'free beer' or in 'free speech'?». Слово «поддержка» с точки зрения Microsoft: вы можете открыть тикет в поддержке Microsoft, и вам окажут квалифицированную поддержку, плюс имеется договор с производителем ОС. Слово поддержка с точки зрения VMware: «мы смогли это запустить». Особенно радует «поддержка» древних систем, которые не поддерживает сам производитель (тот же Microsoft, например).
Поддержка образов больше 2TB появилась в Hyper-V в 2012, а в ESXi — в 2013. Вы, определённо, читаете какие-то специфические ресурсы, раз даже это вам запомнилось как победа VMware. :)
«В итоге я считаю, что нужно выбирать исходя из текущих и планируемых потребностей в каждом случае индивидуально.»
Ну вот я на протяжении всего этого разговора хочу услышать что-то индивидуальное. Пока, к сожалению — только стандартный список FUD (уж простите!) и, скорее, вредных «фич», слышанный мной с десяток раз от продавцов VMware.
5. «Проблемы с ОС после выхода были и их было не мало.»
Ну это совсем FUD — даже без примеров. У любого софта есть некоторые проблемы, для того и выходят постоянно обновления. Плюс Hyper-V Server имеет малый footprint, позволяющий значительно снизить количество обновлений, которые нужно применять, по сравнению с Windows Server с полным интерфейсом и другими ролями.
Что «заведомо устаревшего» в 2008R2? В 2012 появились новые возможности, но Hyper-V 2008R2 до сих пор делает своё дело в консервативных компаниях и проблем никаких нет — поддержка до 2020 года, если я правильно помню, будет длиться. Никто не мешает производить обновление по мере выхода новых версий — это не платный продукт, который нужно каждый раз заново покупать.
ESXi 5.0 был тогда тоже «заведомо устаревший», ведь в конце года вышел 5.1…
6. Ну в статье у вас написано немного по-другому. Если досталась в наследство — ну досталась так досталась. Я думал, была какая-то объективная причина выбора.
Что касается «Windows Server Datacenter» — тут у вас (и у авторов таблички с vmwarearena, на которую вы ссылаетесь) какое-то странное смешение понятий — тип лицензирования виртуальных машин с Windows Server вообще никак не влияет на лицензирование Hyper-V (оно бесплатно). Платный продукт — SystemCenter, с ним и надо сравнивать VMware vSphere 6 Enterprise Plus (желательно — со всеми компонентами SC: мониторинг, автоматизация, резервное копирование, контроль конфигурации).
Про бесплатный ESXi — там же даже HA нет, каким образом он применим в описанной архитектуре?
Ещё раз по поводу загрузки с USB. Дело в том, что такая возможность в Hyper-V Server (не помню точно, возможно, только с версии 2012) была, но Microsoft намеренно запретила самостоятельную установку на (бытовые) флешки. Образы для загрузки с USB были доступны только OEM-партнёрам при условии тестирования и гарантии надежности накопителя.
Сейчас, в основном, от этого даже OEM отказались в пользу SATA DOM, которые втыкаются прямо в разъём на материнской плате и собираются в стандартный RAID1 силами SATA-контроллера.
Если можно, вопрос: блейд-системы IBM уже были до вас. Поскольку дисков в самих лезвиях не было, как производилась загрузка — с SAN? По какой причине было принято решение отказаться от штатного режима загрузки и использовать вместо отказоустойчивой SAN бытовые USB флешки?
Я почему спрашиваю: не примите на свой счёт, просто вы перечислили все «selling points» VMware vs. Hyper-V из методички продавцов VMware. С вами, случайно, поставщик решений VMware не общался на этапе принятия решений? Я не намекаю ни на какую коррупцию, я имею в виду, не ввели ли вас в заблуждение, выдав спорные, но уникальные для VMware возможности за новейшие прогрессивные технологии, которые вы и попытались внедрить?
Добавлю ещё один аргумент против VMware — необходимо, чтобы ваши приемники тоже хорошо знали VMware. Как видите, это не всегда возможно, особенно с учётом специфики гос. предприятий. Вероятность того, что приемники будут разбираться в Windows Server, значительно выше.
Мне хотелось бы услышать/прочитать описание хоть одного реального случая, когда FT сработал, как в рекламных брошюрах. Мне кажется, что вероятность того, что основной сервер так интересно выйдет из строя, что ни байта информации не будет повреждено до момента выхода, достаточно близка к 0. (Отключение питания в ЦОД маловероятно). Если данные всё же были повреждены, то вам не продолжать с ними работать надо, а срочно отменять все текущие транзакции, что и случится в случае падения обычной ноды кластера и *не* произойдёт «благодаря» FT. Поскольку вероятность повреждения данных >0, внедрение VMware FT, на мой взгляд, *ухудшает* этот самый fault tolerance.
Далее, если у вас критический сервис, минутный простой которого во время загрузки на другой ноде кластера недопустим, не имеет режима Active-Active, а запись на диск не имеет транзакционности, то что-то надо менять «в консерватории».
Ваш отказ от FT в итоге — ещё одно подтверждение того, что, как мне кажется, кроме редчайших случаев, технология FT — чисто маркетинговая, созданная для победы по формальному признаку в конкурсах/тендерах.
Что до цены, Вы, видимо, путаете бесплатный Microsoft Hyper-V Server и роль Hyper-V в Microsoft Windows Server. Это разные продукты с точки зрения покупки/лицензии. Hyper-V Server полностью бесплатен.
Лицензировать Windows на виртуальных машинах вам придётся вне зависимости от типа виртуализации, цена будет одна и та же для VMware и Hyper-V.
Поддержка/обновление системы на USB флешке где-то в недрах сервера, на мой вкус, это, скорее, минус. Загрузка с SAN в вашем случае была бы предпочтительней для любой системы виртуализации, мне кажется.
Заниматься подсчётом мегабайтов ОЗУ в системе виртуализации таких масштабов (5 лезвий с «ОЗУ под завязку 192Гб»), это, простите, демагогия. У вас и на последнем этапе написано «используя порядка 30-40% ресурсов ЦПУ и ОЗУ», не спас бы вас «лишний» 1ГБ на ноду.
Про «сыроваты» — это ваше личное «оценочное суждение», как сейчас модно говорить. В 2012 году вышла уже третья по счёту версия, полностью стабильная 2008R2 эксплуатировалась тогда уже 3 года в продакшене по всему миру (что для только появившегося рынка виртуализации — практически, вечность). ESXi вышла в том же 2008 году, что и Hyper-V Server. Предыдущие продукты виртуализации были у обеих компаний.
С учётом вашей же инициативы по переносу всего, что можно, на бесплатный Linux, «подсаживать» при этом всю систему на платный VMware на этапе её создания, мне кажется, противоречивое решение.
Я не настаиваю, что решение выбрать VMware было ошибкой, я лишь не согласен с тем, что оно было «безальтернативным».
UnReal World не так давно вышел в Steam. «Симулятор финского лыжника». :) Игру делает Sami Maaranen с 1992 года. Замечательная игра, лет 10-15 периодически в неё играю.
ADoM тоже есть в Steam. Thomas Biskup с 1994 года (правда, с 9-летним перерывом) делает. Очень популярная игра в своё время была, один из самых популярных рогаликов.
Это то, что в одиночку делается. А open-source проектов куча из 1980-х ещё тянется: NetHack, Angband приходят в голову сразу.
Корпоративных клиентов (от 500 рабочих мест) это предложение не интересует, они давно сидят на Enterprise Agreement, платят в месяц, как правило,
— 8 апреля 2014 (EOL Windows XP);
— 14 июля 2015 (EOL Windows Server 2003);
— апрель 2014 (NIST объявил SSL и TLS<1.1 небезопасными, что автоматически означает попадание в статистику всех серверов, поддерживающих TLS<1.1, в частности, всех IIS на Windows 2008 R1 и всех современных серверов, в которых владельцы решили оставить возможность соединения по SSL/TLS1.0 (при TLS 1.2 по умолчанию) для совместимости с WinXP или старым Android).
Про «эксплойты и трояны, заточенные под него, которые успешно вскрывают базы Keepass», это, конечно, про единственный PoC KeeFarce, который перехватывает расшифрованную базу из памяти, если компьютер администратора уже заражён.
Да, вектор атаки есть такой, но он один и достаточно сложный — нужен полный доступ к компьютеру админа.
А вот перечислять векторы атаки на Thycotic можно очень долго: это все атаки на IIS, атаки на ASP.NET код самого Thycotic, атаки на Windows на веб-сервере, атаки на компьютеры пользователей, включая браузер, фишинг и реальный MitM (прокси-сервер с доверенным корневым сертификатом и т.д.)…
С сервера (или из резервной копии) нужно украсть один файлик — «encryption.config», после чего можно идти читать всю базу без всяких DLL injection. Мастер-пароль KeePass хотя бы не хранится в файле на диске.
Охранять сервер с Thycotic нужно как зеницу ока, при этом к нему должны иметь доступ множество людей (или заводить отдельный сервер для каждого уровня доступа?). «Главный» админ (или админы) всё равно всё сможет прочитать в обход всех журналов аудита, вытянув encryption.config и базу не с прода, так из бэкапа. Если сервер в AD, то все, кто могут на него полиси поставить, опять же, могут получить encryption.config. Резервные копии сервера нужно делать? Тот, кто к ним имеет доступ и может их расшифровать, будет иметь все пароли. Админ WSUS? Не проблема сделать ручной пакет обновлений. Даже админ антивируса, в некоторых случаях, может, наверное, как-то заставить антивирус файлик этот взять «для анализа». Все эти люди в случае KeePass не будут иметь доступа — пусть даже они смогут украсть .kbdx — он зашифрован, ключ им неизвестен.
Остаются админы филиалов и прочие, которые доступа к центральной инфраструктуре не имеют? Им хватит AD/RADIUS/TACACS, зачем изобретать велосипед?
При этом нам надо дать полнейшие права серверу Thycotic на полный доступ ко всей абсолютно инфраструктуре. Если даже в конторе 2 человека всего IT: сисадмин и сетевой админ, и то ни у одного из них не будет такого доступа, который требуется Thycotic. В больших организациях такой доступ из одной точки вовсе немыслим.
В конце концов, в случае катастрофы в инфраструктуре админам останется только сидеть и кусать локти, если доступа к северу Thycotic нет.
Но для проверок всё очень красиво с Thycotic — логи аудита, ролевой доступ, автоматическая ротация паролей — аудиторы и менеджеры будут в восторге. А кому надо — все пароли получат без всяких записей в логи.
— Доктор, когда я делаю вот так, у меня вот тут болит!
— А вы вот так не делайте!
И под «руками» я имел в виду "ручное редактирование списка контроля доступа на закладке Security в свойствах политики в режиме её редактирования". Использование инструмента Security Filtering на первой странице Group Policy Editor я бы не стал называть ручным редактированием: он даёт упрощённую и наглядную картину. И как бы мы не называли использование инструмента Security Filtering, работать этот инструмент после применения обновления перестаёт.
Если честно, то мне кажется, мы ходим по кругу. Создайте тестовую политику и посмотрите, чем отличается инструмент GPEdit Security Filtering от редактирования списка контроля доступа (закладка Security в свойствах политики).
Особенный контраст вы заметите, если между вашей рабочей станцией и контроллером домена будет хотя бы 10-20ms пинга, но это так, дополнительный «бонус», в статье не про это речь.
Возможно, вы путаете инструмент Security Filtering (изображён на скриншоте «Список фильтров безопасности (security filtering)» в статье) и закладку Security при редактировании политики? Это разные (хоть и связанные) инструменты. Ручное редактирование в закладке Security будет работать, если вы всю оставшуюся жизнь будете помнить, что там теперь нельзя убирать read для Authenticated Users (не заменив его Domain Computers).
1. Создаём тестовую политику с правами по умолчанию.
2. Заходим в Security Filtering на первой странице политики.
2.1. Добавляем группу, к которой политика должна применяться.
2.2. Удаляем Authenticated Users (автоматически удаляется и read и apply!).
3. В случае user scope политики получаем ошибку применения, если установлено обновление.
4. Руками добавляем Domain Computers/Authenticated Users в Security.
5. Только после этого политика начинает работать.
Вопрос — зачем теперь нужен secuirty filtering, если нам надо потом руками лезть в список контроля доступа?
Приведённая инструкция возвращает нормальное поведение security filtering: убираем authenticated users, добавляем нужную группу — всё сразу работает.
В зависимости от ОС, номер непосредственно устанавливаемого обновления в WSUS будет различаться, я добавил все номера в статью.
Ещё раз в двух словах: «решение» AD DS Team предполагает фактически отказ от использования Security Filtering и необходимость помнить это «решение» как «Отче наш» при каждом создании/изменении политик.
Предложенное изменение схемы AD делает только одну вещь: автоматизирует то же действие, которое предписывается делать каждый раз руками, следуя «решению» AD DS Team.
Более того, я целый абзац «Предупреждение» посвятил альтернативе для тех, кто не готов изменять схему.
Поведение политик не менялось 16 лет, и, если Microsoft вдруг захочется изменить его ещё раз, то всем, вне зависимости от того, следовали они этой статье или нет, придётся снова что-то менять.
Отменить предложенное изменение схемы можно в любой момент, убрав SDDL-вставку так же, как она была добавлена. Даже если это сделать спустя много лет, результат будет 100% тот же, как если бы все эти годы администратор вручную следовал решению AD DS Team, добавляя Domain Computers в новые политики. Никаких других изменений не предлагается.
1. Собственно, драйвера без подписи WHQL, и, соответственно, без тестирования WHC просто нельзя установить на 64-битных Windows Server. Я понимаю, что вы хотите сказать, но, мне кажется, что это из разряда «зелен виноград».
2. Вы можете для себя, конечно, устанавливать сколь угодно мягкие рамки, но стандарты индустрии, например, §6.2 PCI DSS требуют установки обновлений безопасности на критические системы максимум в течение месяца, на остальные — трёх. Коммутаторы и прочее сетевое оборудование входит в список систем, подлежащих обновлению. Даже если вашей компании не требуется формальная сертификация, прислушиваться к стандартам, мне кажется, всё равно стоит.
3. Если задача — работать строго с системой виртуализации, не пересекаясь ни с какими другими подсистемами, специализируясь только в этой узкой области, изучая только её, то, возможно, одна программа-агрегатор удобнее. Если же виртуализация — просто ещё один инструмент в руках системного администратора, то чем повторять в отдельной консоли все функции, которые уже есть в других, имеет смысл просто добавить недостающие. Hyper-V — всего лишь ещё одна роль Windows Server, SCVMM — ещё один компонент SC.
Более того, решение задач настройки Windows Server всё больше дрейфует в сторону единой консоли, имя которой — PowerShell.
5. Ок, принимаю к сведению ваши наблюдения. Единственное, я не уверен, что вы не путаете поставку в виде универсального OVF с отсутствием поддержки/невозможностью запуска под Hyper-V. Приведу пример: OSSIM. Формально (как минимум раньше, сейчас может уже записали «поддержку»), был ISO образ для установки на голое железо или на VMware. Реально — всё работало под Hyper-V даже со старым ядром, включая анализ копии сетевого трафика. Поддержки в смысле службы поддержки нет ни под VMware ни под Hyper-V — OpenSource.
6. Я не разделяю ваше понимание, HNV — полная виртуализация, всё заворачивается в NVGRE (а в новой версии, и, опционально, в VXLAN). За что VMware просит столько денег при наличии конкурирующих бесплатных (или более дешёвых, в случае SCVMM) решений — мне лично непонятно.
«А вообще просто лично меня задели сильно эти изменения, простите, не удержался. Кстати, S2D будет только в старшей редакции.»
Я тоже не в восторге от этого изменения политики лицензирования Windows, но эта проблема одинаково коснётся пользователей всех систем виртуализации. Что до S2D, я поначалу тоже стал проклинать маркетологов, но потом подумал, что при реальном внедрении там и так уже будет Datacenter для виртуальных машин в большинстве случаев. Хотя, всё равно обидно, да.
«И хочу сказать, что и за vmware, и за Hyper-V есть аргументы. Иначе, наверное, vmware бы уже прекратила существование.»
В наш век маркетинга как раз более продвинутые, на мой взгляд, BlackBerry OS 10 и Windows на мобильниках прекращают своё существование, а покупатели стоят в очередях за очередным iPhone и Galaxy S7.
У VMware более удачная политика продвижения, они на рынке дольше и у всех на слуху, как ксерокс фирмы Xerox. Немалую роль играет и, в моём понимании, не очень честный подход со стороны сертифицированных VMware системных администраторов: они вложили немалые деньги в своё обучение и сертификацию, плюс боятся конкуренции с обычными администраторами Windows, так как никаких arcane знаний администрирование Hyper-V не требует. Поскольку начальство/заказчик всё равно не могут сделать осознанный выбор, решение использовать ту или иную платформу полностью отдаётся на откуп системным администраторам, а те необъективны в своём выборе, и, для сохранения своих инвестиций и защиты рабочего места, покупают (на деньги заказчика/работодателя!) дорогостоящую систему от VMware при наличии однозначно не худшей бесплатной альтернативы от Microsoft.
Я также читал, что VMware платит интеграторам просто за факт предложения VMware в новых проектах, но это, возможно, FUD — не поручусь.
Пока я насобирал следующий список преимуществ (без кавычек) VMware:
— vSAN (хотелось бы ещё увидеть статистику реальных внедрений, ведь необходимо совсем другое оборудование, чем для классической виртуализации), который появился относительно недавно и через пару месяцев получит конкурента в виде S2D.
— Какие-то проприетарные виртуальные appliances. Опять же — совсем нишевый случай.
То есть абсолютное большинство инсталляций VMware последних лет не имели под собой никакого фактического обоснования.
Решения на базе Hyper-V я внедряю где-то с конца 2009 года, то есть примерно с выхода 2008R2. С VMware ESX/ESXi работал с версиями 2-4. Как я уже писал, со времён выхода Hyper-V 2008R2 я не вижу смысла при прочих равных в использовании VMware, потому и задаю вопросы тем, кто остался на VMware, как оно там.
«Но также я ненавижу настроенный Windows: обязательно где-то забудешь снять/поставить галочку и система будет себя вести непредсказуемо, пока не найдёшь искомую галочку.»
Или я вас неправильно понимаю, или вы неправильно «готовите» Windows Server: для того и существуют GPO, SCCfgMgr и прочие Desired State Configuration, чтобы по возможности никогда не лезть в настройки продакшена руками. В крайнем случае, идёт запись всех действий в систему контроля изменений с последующим превращением записи в CMS в пошаговую инструкцию. Искать каждый раз галочку, это, конечно, олдскульно, но, мне кажется, так давно не стоит делать.
Что до поддержки двух систем в одной организации, это мне кажется странной идеей: правильное разделение основных и резервных мощностей, production и staging требует как раз унификации, а не различия между платформами. В то же время, поддержка двух платформ в дополнение ко всем вышеперечисленным разделам приведёт к дикому раздутию штата и бюджета IT, а на дворе кризис, бизнес впервые начал считать деньги. И, главное, я не вижу как именно фирма-поставщик виртуализации (не, скажем, одновременное обновление, а именно марка системы) может быть той SPoF, которой следует избегать любой ценой.
И навыки администрирования AD/GPO пригодятся, и PowerShell, и mmc, и подсистема Event-ов, включая возможность централизованного сбора, и Failover Cluster Manager, и Windows Firewall с IPSEC, и Performance Monitor и другие средства мониторинга — это просто Windows Server с полутора ролями. Человек со знанием Windows Server сможет администрировать Hyper-V сервера значительно за пределами «GUI, где всё подписано».
1. «Отсутствие драйверов — это благо!», «Мир — это война!», «Свобода — это рабство!»…
2. Отказ от установки обновлений как-то странно обсуждать даже. Ваше право, но это уже давно плохая практика. Даже если своего понимания нет, почему так не стоит делать, аудиторы не дадут. Для чего в кластере cattle молиться на аптайм — не представляю. Cluster-aware update те немногие обновления, которые нужны Hyper-V, заливает сам по очереди на все ноды.
3. Эффект утёнка? Стандартный стиль mmc, всё в общей парадигме Windows Server management.
4. Windows Server SA (который, по хорошему, и так должен быть у всех, при наличии виртуальных машин с Windows Server) даёт право на поддержку, не premier, но и не Technet. Premier это, по сути, замена штатной единице, стоит соответственно. Покупать ли поддержку у Microsoft — ваш выбор. Пользователей VMware никто не спрашивает.
5. Можно статистику в качестве пруфа или пояснение термина «основной»? OVF вообще как бы независимый стандарт для обмена, MVMC его импортирует.
6. С vSAN соглашусь — свою специфическую нишу решение имеет. S2D, действительно, выйдет через пару месяцев.
Что до NSX, я, может, что-то пропустил, но vCloud Networking and Security (ныне NSX) догнал SCVMM 2012 SP1 (в котором уже была технология SDN) только в 2013 году. Это не то что не «VMware-only технология», тут VMware в догоняющих. Более того, при цене одной лишь NSX, насколько я знаю, «от $5k за процессор», нужно ещё поискать того, кто её в здравом уме купит.
7. Насколько «красивее» чужеродная в среде Windows-серверов технология «сама-в-себе» лучше спросить у стандартного Windows-админа, которому вместо привычных систем достаётся в наследство такое чудо. Вон ниже в треде человек перепутал HA и FT, и немудрено.
Представлять же благом отсутствие интеграции с централизованной аутентификацией, менеджментом и мониторингом (для которых, внезапно, необходимы сервера аутентификации AD), замена привычных средств (mmc, WMI, PowerShell и т.д.) самоделками — это продолжение вашего пункта 1: «Любовь — это ненависть!»
«Хотя, с введением per-core licensing в WS2016 и возвращением функциональных отличий в редакциях всё может вдруг стать не так однозначно…»
Почему все VMware-админы приплетают к Hyper-V лицензирование Windows Server (как будто в середе VMware можно их не лицензировать!), для меня загадка. Видимо, все VMware-ресурсы друг у друга таблички перерисовывают без понимания, а вы потом их читаете, не разбираясь. Повторю ещё раз: Hyper-V — бесплатный гипервизор.
«P.S. А вот с FUDом по поводу нежелания переводить рабочие системы резко на новейший Win Server вы точно погорячились.»
Простите, вы перевираете. FUD-ом я назвал FUD про «проблемы ОС».
«Кто в здравом уме будет грабли собирать на боевых нагрузках? Тем более, когда речь об ОС — в этом случае и железо тоже должно быть совместимо. А вендоры еще не собрали баги в новых драйверах… Чур меня, чур! Год минимум от релиза. В лабе погонять — другое дело конечно, там и с technical preview начинать можно.»
Я так и написал — хотите консервативный подход — был (в 2012) Hyper-V Server 2008R2, который уже 3 года был в продакшене. Когда дозреете для апгрейда — гипервизор бесплатный, покупать новую версию не надо.
А если «год минимум до релиза», то автору нельзя было и ESXi 5.0 ставить — ей тогда года не было.
Предлагаю отойти от риторики холиваров и, если хотите, продолжить более предметно, а не «нравится — не нравится».
Из всех ваших пунктов я себе на заметку могу взять лишь vSAN. В условиях миниатюризации и всё большей специализации вычислительных нод я не уверен, что за гиперконвергентностью светлое будущее, но согласен, что наличие функциональности — это плюс. Для кого-то, возможно, это станет решающим фактором. Через несколько месяцев и в этом вопросе будет достигнут паритет.
Сразу оговорюсь, это не холивар, мне интересно сравнить впечатления и обменяться опытом. Я не «не люблю VMware» (как вы со смайликом написали в другом комментарии), я не вижу смысла его использовать при прочих равных, потому мне интересно услышать от тех, кто его всё-таки выбрал, о причинах — что я пропустил?
По пунктам:
1. Ну, то есть, фактически, вариант выключения питания. Да, красиво, на всех демо-стендах именно его и показывают. Практика, однако, даже моя личная, говорит скорее о возможности выхода из строя материнской платы, памяти, контроллера хранения с ненулевой вероятностью silent corruption данных в момент, предшествующий окончательному выходу из строя. В некоторых случаях приходится вообще откатывать данные из архива/снэпшота, при возможности, проводить ручную проверку, слияние последних данных и архивной копии и т.д. Продолжить выполнять задачу на другой ноде как ни в чём не бывало в таком случае — однозначное зло. Даже если мы примем, что вероятность «атомарной» поломки выше, чем пролонгированной с периодом silent corruption, вероятность последнего варианта ведь не 0. В таком случае, стоит очень хорошо подумать с точки зрения менеджмента рисков, что хуже — пару минут downtime или повышение вероятности повреждения данных.
Сразу прокомментирую и соседнюю ветку:
" Вы не считаете, что отказоустойчивость нод кластера для важных систем — это хорошо? Понятное дело, что стоит вопрос в реализации… Но всё же? "
Я уже писал выше — отказоустойчивость для важных систем должна достигаться на уровне приложения: active-active, транзакции, проверка целостности данных. Если этого нет, значит данные не такие уж и важные. Отказоустойчивость именно *нод* кластера — это подход pet (vs. cattle), он себя изжил, а в данном случае, с точки зрения менеджмента рисков — мы увеличиваем риски, внедряя VMware FT.
2. Так и Windows Server с ролью Hyper-V не требует покупки дополнительной лицензии, если у вас хоть одна виртуалка с Windows Server внутри лицензирована. Вас кто-то ввёл в заблуждение, нет за это оплаты и в таком случае. Есть платный SystemCenter, но это совсем другой продукт, виртуализация там — лишь один из компонентов.
3. Мне кажется, тут никаких вариантов кроме сесть на телефон и не слезать с гарантийной поддержки до полного исправления ситуации просто нет. Если прошивка контроллеров заведомо дефектная, ставить такие контроллеры в продакшен на основании того, что после загрузки они пока ни разу не глючили — неверно.
И, опять же, менеджмент рисков говорит, что нода, которая не загрузилась (она не под нагрузкой, есть ещё 4 других и вторая площадка) представляет меньшую опасность, чем внезапное повреждение системного раздела под полной нагрузкой и, в лучшем случае, выход из строя ноды в случайный момент (вероятно, под нагрузкой), а в худшем — опять же, повреждением данных.
4. Про FT — выше. Как инженер, мне кажется, вы должны были не только в FUD-таблички вроде этой смотреть. В ней, между прочим, к каждой второй строчке надо добавить сноску, плюс там нет ни одной строчки с функциональностью, которая лучше в Hyper-V (если совсем нельзя было пропустить, сделана обобщающая строчка, а в ней через запятую указана в том числе киллер-фича Hyper-V, так что и непонятно, это вообще плюс, минус или просто другое название).
И вы, простите, продолжаете, верю что неосознанно, идти по методичке. Следующий стандартный пункт — «поддержка ОС». «Free as in 'free beer' or in 'free speech'?». Слово «поддержка» с точки зрения Microsoft: вы можете открыть тикет в поддержке Microsoft, и вам окажут квалифицированную поддержку, плюс имеется договор с производителем ОС. Слово поддержка с точки зрения VMware: «мы смогли это запустить». Особенно радует «поддержка» древних систем, которые не поддерживает сам производитель (тот же Microsoft, например).
Поддержка образов больше 2TB появилась в Hyper-V в 2012, а в ESXi — в 2013. Вы, определённо, читаете какие-то специфические ресурсы, раз даже это вам запомнилось как победа VMware. :)
«В итоге я считаю, что нужно выбирать исходя из текущих и планируемых потребностей в каждом случае индивидуально.»
Ну вот я на протяжении всего этого разговора хочу услышать что-то индивидуальное. Пока, к сожалению — только стандартный список FUD (уж простите!) и, скорее, вредных «фич», слышанный мной с десяток раз от продавцов VMware.
5. «Проблемы с ОС после выхода были и их было не мало.»
Ну это совсем FUD — даже без примеров. У любого софта есть некоторые проблемы, для того и выходят постоянно обновления. Плюс Hyper-V Server имеет малый footprint, позволяющий значительно снизить количество обновлений, которые нужно применять, по сравнению с Windows Server с полным интерфейсом и другими ролями.
Что «заведомо устаревшего» в 2008R2? В 2012 появились новые возможности, но Hyper-V 2008R2 до сих пор делает своё дело в консервативных компаниях и проблем никаких нет — поддержка до 2020 года, если я правильно помню, будет длиться. Никто не мешает производить обновление по мере выхода новых версий — это не платный продукт, который нужно каждый раз заново покупать.
ESXi 5.0 был тогда тоже «заведомо устаревший», ведь в конце года вышел 5.1…
6. Ну в статье у вас написано немного по-другому. Если досталась в наследство — ну досталась так досталась. Я думал, была какая-то объективная причина выбора.
Что касается «Windows Server Datacenter» — тут у вас (и у авторов таблички с vmwarearena, на которую вы ссылаетесь) какое-то странное смешение понятий — тип лицензирования виртуальных машин с Windows Server вообще никак не влияет на лицензирование Hyper-V (оно бесплатно). Платный продукт — SystemCenter, с ним и надо сравнивать VMware vSphere 6 Enterprise Plus (желательно — со всеми компонентами SC: мониторинг, автоматизация, резервное копирование, контроль конфигурации).
Про бесплатный ESXi — там же даже HA нет, каким образом он применим в описанной архитектуре?
Сейчас, в основном, от этого даже OEM отказались в пользу SATA DOM, которые втыкаются прямо в разъём на материнской плате и собираются в стандартный RAID1 силами SATA-контроллера.
Если можно, вопрос: блейд-системы IBM уже были до вас. Поскольку дисков в самих лезвиях не было, как производилась загрузка — с SAN? По какой причине было принято решение отказаться от штатного режима загрузки и использовать вместо отказоустойчивой SAN бытовые USB флешки?
Я почему спрашиваю: не примите на свой счёт, просто вы перечислили все «selling points» VMware vs. Hyper-V из методички продавцов VMware. С вами, случайно, поставщик решений VMware не общался на этапе принятия решений? Я не намекаю ни на какую коррупцию, я имею в виду, не ввели ли вас в заблуждение, выдав спорные, но уникальные для VMware возможности за новейшие прогрессивные технологии, которые вы и попытались внедрить?
Далее, если у вас критический сервис, минутный простой которого во время загрузки на другой ноде кластера недопустим, не имеет режима Active-Active, а запись на диск не имеет транзакционности, то что-то надо менять «в консерватории».
Ваш отказ от FT в итоге — ещё одно подтверждение того, что, как мне кажется, кроме редчайших случаев, технология FT — чисто маркетинговая, созданная для победы по формальному признаку в конкурсах/тендерах.
Что до цены, Вы, видимо, путаете бесплатный Microsoft Hyper-V Server и роль Hyper-V в Microsoft Windows Server. Это разные продукты с точки зрения покупки/лицензии. Hyper-V Server полностью бесплатен.
Лицензировать Windows на виртуальных машинах вам придётся вне зависимости от типа виртуализации, цена будет одна и та же для VMware и Hyper-V.
Поддержка/обновление системы на USB флешке где-то в недрах сервера, на мой вкус, это, скорее, минус. Загрузка с SAN в вашем случае была бы предпочтительней для любой системы виртуализации, мне кажется.
Заниматься подсчётом мегабайтов ОЗУ в системе виртуализации таких масштабов (5 лезвий с «ОЗУ под завязку 192Гб»), это, простите, демагогия. У вас и на последнем этапе написано «используя порядка 30-40% ресурсов ЦПУ и ОЗУ», не спас бы вас «лишний» 1ГБ на ноду.
Про «сыроваты» — это ваше личное «оценочное суждение», как сейчас модно говорить. В 2012 году вышла уже третья по счёту версия, полностью стабильная 2008R2 эксплуатировалась тогда уже 3 года в продакшене по всему миру (что для только появившегося рынка виртуализации — практически, вечность). ESXi вышла в том же 2008 году, что и Hyper-V Server. Предыдущие продукты виртуализации были у обеих компаний.
С учётом вашей же инициативы по переносу всего, что можно, на бесплатный Linux, «подсаживать» при этом всю систему на платный VMware на этапе её создания, мне кажется, противоречивое решение.
Я не настаиваю, что решение выбрать VMware было ошибкой, я лишь не согласен с тем, что оно было «безальтернативным».
ADoM тоже есть в Steam. Thomas Biskup с 1994 года (правда, с 9-летним перерывом) делает. Очень популярная игра в своё время была, один из самых популярных рогаликов.
Это то, что в одиночку делается. А open-source проектов куча из 1980-х ещё тянется: NetHack, Angband приходят в голову сразу.