Комментарии 69
110. Кросс.
Помню, как в 2010 или 11 мы его выламывали и заменяли на бюджетные панели RJ45, потому что уже наелись…
Помню, как в 2010 или 11 мы его выламывали и заменяли на бюджетные панели RJ45, потому что уже наелись…
Свои мучения со 110 кроссом я вспоминаю с ужасом. В данной конкретной ситуации, я уверен, это была просто потеря времени. Имело бы хоть какой-то смысл ставить кросс при необходимости нарастить длину. Но руководство хотело чтобы дёшево и универсально. Дешевле и в наличии в городе больше ничего не было.
такой бардак бывает не только в госах, в 2009 аналогично поднимал коммерческую структуру, причем финансово успешную.
Большая пасажиро-транспортная компания, работает в 18-и городах, инраструктура собрана из г-мна и палок =/
И, как обычно, вся аргументация, уверен, сводится к «ну ведь работает же»…
Очень интересно, спасибо.
(нашёл опечатку: «обьеспечить»)
(нашёл опечатку: «обьеспечить»)
У меня внезапный вопрос: а почему одни и те же люди занимаются внешним видом стоек и настройкой сети? В коммерческих сетях давно есть разделение полномочий: есть люди, которые хорошо знают как должны выглядеть подключения с точки зрения сети и электричества и есть люди, которые хорошо знают как настраивать сети. Когда две эти компетенции пересекаются — они никаким образом не делают общую компетенцию лучше, так как никакой синергии между двумя этими компетенциями нет.
(Вопрос: почему не были использованы мощности коммерческих ДЦ для размещения?)
(Вопрос: почему не были использованы мощности коммерческих ДЦ для размещения?)
Смею предположить — Потому что государство… Ну и до кучи, все что государственное, должно быть у государства, а не у держателей коммерческих ДЦ как бы.
Читал где-то полгода назад о том, что есть/были планы всё перевести в подконтрольные государству ЦОД… Информации о том, как успехи, найти не смог.
Каждому ОГВ дали время до, если не ошибаюсь, середины 2017 года на обдумывание сколько и чего требуется от ростелекома чтобы переехать к ним. Что будет дальше пока не понятно.
Ооооо… Хотел бы я посмотреть на эти хотелки. Помню, как мне носили заявки на наши ресурсы: взвесьте нам десяток топовых ксеонов, пару сотен гигабайт ОЗУ, ну и пару десятков терабайт на первом raid… Но после разъяснительной беседы и пары вопросов о нагрузках и методах подсчёта планируемого потребления это всё умещалось на дохленькой однопроцессорной виртуалке с 512 ОЗУ и 50Гб диска. И работало годами.
Думаю, при переезде в Ростелекомовские ЦОД будет так: любой каприз за ваши деньги. Под каждую ГИС отдельный ЦОД? Всегда пожалуйста!
Думаю, при переезде в Ростелекомовские ЦОД будет так: любой каприз за ваши деньги. Под каждую ГИС отдельный ЦОД? Всегда пожалуйста!
Новый императорский ЦОД готовили к открытию три года. Наконец, все работы были завершены, и император пригласил всю знать полюбоваться красотой ЦОДа.
Все были в восторге и рассыпались в комплиментах. Но императора интересовало мнение Мастера Лин-чи, который считался непревзойдённым знатоком этого вида искусства. Когда император обратился к Лин-чи, все присутствующие обернулись, и воцарилась тишина. Лин-чи ответил:
— Странно, но я не вижу ни одного белого болта в черных стойках. Как жизнь может существовать без смерти? Из-за того, что здесь нет обрезков изоляции UTP5, ЦОД мёртв. Я думаю, что сегодня утром его очень тщательно подметали. Прикажите принести немного RJ-45 измазанных в побелке.
Когда разноцветные кусочки проводов витой пары принесли и разбросали, ветер из кондиционера начал играть ними. Хруст мусора под ногами — и ЦОД ожил!
Мастер сказал:
— Теперь всё в порядке. Ваш ЦОД прекрасен, но он был слишком ухожен. Искусство становится величайшим, когда не обнаруживает себя.
Все были в восторге и рассыпались в комплиментах. Но императора интересовало мнение Мастера Лин-чи, который считался непревзойдённым знатоком этого вида искусства. Когда император обратился к Лин-чи, все присутствующие обернулись, и воцарилась тишина. Лин-чи ответил:
— Странно, но я не вижу ни одного белого болта в черных стойках. Как жизнь может существовать без смерти? Из-за того, что здесь нет обрезков изоляции UTP5, ЦОД мёртв. Я думаю, что сегодня утром его очень тщательно подметали. Прикажите принести немного RJ-45 измазанных в побелке.
Когда разноцветные кусочки проводов витой пары принесли и разбросали, ветер из кондиционера начал играть ними. Хруст мусора под ногами — и ЦОД ожил!
Мастер сказал:
— Теперь всё в порядке. Ваш ЦОД прекрасен, но он был слишком ухожен. Искусство становится величайшим, когда не обнаруживает себя.
Один из вопросов в бюджете, он здесь и рассмотрен в том числе, можно нанять интегратора в котором будут отдельные спецы по кросам, панасоникам, цискам и броадвелам, возможно даже с высокой компетенцией, вопрос в цене(тут описанный первый этап выходит 10млн, при их подключении), да без того кто понимает в разных областях, т.е. задаст стандрат(суть тех.дир.), получится как в самом начале: «вдруг придётся переместить стойку в дальний угол помещения, как тогда быть?»
P.S. Спасибо, автор, за этот детектив.
P.S. Спасибо, автор, за этот детектив.
В данном случае это является ярким примером экономического фактора. А для того, чтобы потратить эти 10 млн их нужно сначала получить, а чтобы их получить… И тут мы увидим временной фактор: когда рак на горе свистнет. Интеграторы также бывают как адекватные, так и не очень. В случае неадекватного интегратора (опыт общения имеется) процесс устранения неисправностей и внесения необходимых изменений возвращает нас к временному фактору (а часто и экономическому).
Не дай бог сейчас ещё заговорить о квалификации специалистов…
Не дай бог сейчас ещё заговорить о квалификации специалистов…
Вы не правильно понимаете. Не нанять специальных откатных интеграторов, а просто разметиться в коммерческом ЦОДе, который уже давно съел всех собак в округе на монтаже и обслуживании.
См. ниже. Померив расстояния по картам могу сказать, что даже на сегодняшний день размещение всего оборудования в имеющихся коммерческих ЦОД у нас не будет отвечать принципу катастрофоустойчивости. Хотя, честно говоря, я вообще не уверен, что где-то ещё в стране у нас этот принцип вообще соблюдается.
Могу точно сказать, что арендовались стойко-места в коммерческих ЦОД. Но, опять же, на момент начала работ ЦОД у нас был только один. С моей точки зрения через средства удалённого управления вообще было всё равно где физически располагается оборудование: под боком или на другом конце земли.
Могу точно сказать, что арендовались стойко-места в коммерческих ЦОД. Но, опять же, на момент начала работ ЦОД у нас был только один. С моей точки зрения через средства удалённого управления вообще было всё равно где физически располагается оборудование: под боком или на другом конце земли.
Спасибо за вопросы!
На первый даже не знаю как ответить. Если развёрнуто, то тянет на ещё одну статью о проблемах отрасли. Если кратко, то я думаю Вы и сами понимаете причины: экономические, кадровые, организационные, политические. Считаю ли я данную ситуацию нормальной? Нет не считаю. Каждый должен заниматься своим делом, должна быть команда. Хотя знаю людей, твёрдо считающих, что инженер — это универсальный специалист: и полы мыть, и сервера крутить.
Само решение о создании ЦОД было принято до начала моей работы. От себя добавлю, что у нас как таковых коммерческих ЦОД не было (только Синтерра, ныне Мегафон). Ростелеком открыл свой ЦОД позже государственного. Дешевых ресурсов (облачных, виртуальных) не предлагал у нас никто. Также никто не отменял условие катастрофоустойчивости, в любом случае должно было быть несколько площадок, а их физически не существовало. Возможно, если бы решение принималось сейчас, то оно было бы в пользу аренды стойко-мест. Хотя с другой стороны, государственные системы должны работать в государственном ЦОД...???
Поэтому оставался выбор: строить свой или ждать, пока ставропольский бизнес создаст условия.
На первый даже не знаю как ответить. Если развёрнуто, то тянет на ещё одну статью о проблемах отрасли. Если кратко, то я думаю Вы и сами понимаете причины: экономические, кадровые, организационные, политические. Считаю ли я данную ситуацию нормальной? Нет не считаю. Каждый должен заниматься своим делом, должна быть команда. Хотя знаю людей, твёрдо считающих, что инженер — это универсальный специалист: и полы мыть, и сервера крутить.
Само решение о создании ЦОД было принято до начала моей работы. От себя добавлю, что у нас как таковых коммерческих ЦОД не было (только Синтерра, ныне Мегафон). Ростелеком открыл свой ЦОД позже государственного. Дешевых ресурсов (облачных, виртуальных) не предлагал у нас никто. Также никто не отменял условие катастрофоустойчивости, в любом случае должно было быть несколько площадок, а их физически не существовало. Возможно, если бы решение принималось сейчас, то оно было бы в пользу аренды стойко-мест. Хотя с другой стороны, государственные системы должны работать в государственном ЦОД...???
Поэтому оставался выбор: строить свой или ждать, пока ставропольский бизнес создаст условия.
Читаю, читаю, и чувствую, что-то родное. Ну вот, ну где-же хоть краешек скриншота/фото с упоминанием? Ах вот оно, в конце! ...26.ru Спасибо! Оторваться от статьи не мог. Работа и правда проделана колоссальная и с применением опыта.
А какие были взаимоотношения с нашими регуляторами ИБ? Проверяли ГИС?
Всякие аттестаты соответствия, наличие лицензированных средств защиты, отечественная криптография и тд.
Всякие аттестаты соответствия, наличие лицензированных средств защиты, отечественная криптография и тд.
Привет! Сделано действительно много и качественно. Вопрос… Какой опыт был за плечами до этого? Сколько платили и сколько предложили на новом месте (можно хоть в процентах, хоть в литрах молока :) )? Было-ли чувство «неизвестности» в начале и чётко и уверенно шёл к цели?
Как оказалось, было очень много неиспользованного опыта: образование и программирование. Образование — инженер-системотехник (АСОУ). Но задолго до него был большой опыт программирования (до поступления в ВУЗ было что-то около 6 лет опыта). Совместно это позволяет понимать как работает та или иная технология, понял как работает — дальше уже дело техники. Программировать начал лет с 10, с 14-15 уже за деньги. Прошёл весь курс от ассемблера и машинных кодов до PHP и VBA, через C/C++, Pascal и прочие Delphi. Знания по защите информации были получены на практике. =)
Платили мало, в пределах 800-1000$. На новом месте — в два раза больше и руководящая должность, пока работал зарплата росла. Но весь рублёвый рост съел кризис. Теперь выбираю куда пойти дальше, т.к. тут в моих знаниях уже потребности нет (у нас тут VLAN — это практически инструмент дьявола, нам просто нужен интернет...) =))) Для справки: средняя зарплата в ИТ отрасли в нашем регионе сейчас порядка 20-30 тыр, тогда была 15-20 тыр.
Чувства неизвестности не было, было понимание того, что нужно сделать и несколько вариантов как это можно сделать (обычно от «написать/собрать» до «купить»), выбираем оптимальный и приступаем к работе. Жаль, что не всё успел реализовать…
Платили мало, в пределах 800-1000$. На новом месте — в два раза больше и руководящая должность, пока работал зарплата росла. Но весь рублёвый рост съел кризис. Теперь выбираю куда пойти дальше, т.к. тут в моих знаниях уже потребности нет (у нас тут VLAN — это практически инструмент дьявола, нам просто нужен интернет...) =))) Для справки: средняя зарплата в ИТ отрасли в нашем регионе сейчас порядка 20-30 тыр, тогда была 15-20 тыр.
Чувства неизвестности не было, было понимание того, что нужно сделать и несколько вариантов как это можно сделать (обычно от «написать/собрать» до «купить»), выбираем оптимальный и приступаем к работе. Жаль, что не всё успел реализовать…
Ну… С такой базой за плечами не удивительно, что всё получилось :)
Cтранно, что предложили больше чем в гос. конторе, но при этом вланов бояться… Чудаки.
Я вроде как с зп в 45 админ/хелпдескер. Вот второе конкретно так напрягает и тормозит в развитии, не заняться своими делами, всё этим манагерам неймётся что-либо сломать… Думаю в СПб твои знания выйдут в 120к+ всё ж основная магистраль именно отсюда идёт и ЦОД'ы тут постоянно строят.
Cтранно, что предложили больше чем в гос. конторе, но при этом вланов бояться… Чудаки.
Я вроде как с зп в 45 админ/хелпдескер. Вот второе конкретно так напрягает и тормозит в развитии, не заняться своими делами, всё этим манагерам неймётся что-либо сломать… Думаю в СПб твои знания выйдут в 120к+ всё ж основная магистраль именно отсюда идёт и ЦОД'ы тут постоянно строят.
Спасибо! =) Желаю поменьше хелпдеска!
В своё время я фактически работал в банковском хелпдеске. Т.к. по понятным причинам программировать было нельзя, пришлось пользоваться тем, что есть — Microsoft Office + VBA. Я себе целую гору автоматизации на этом бейсике написал, что-то меня пережило ещё на несколько лет. Но основная суть была в том, чтобы автоматизировать рутинные процессы хелпдеска.
В своё время я фактически работал в банковском хелпдеске. Т.к. по понятным причинам программировать было нельзя, пришлось пользоваться тем, что есть — Microsoft Office + VBA. Я себе целую гору автоматизации на этом бейсике написал, что-то меня пережило ещё на несколько лет. Но основная суть была в том, чтобы автоматизировать рутинные процессы хелпдеска.
Вроде да… Видел как в армии ребята тоже писали всякое-разное на нём (https://habrahabr.ru/post/237641/), но вот сейчас даже прикинуть не могу, что же там можно автоматизировать… Есть 1С 7.7 с кучей прикруток/обработок и программистом тамошним, собственно вроде как всё пытаются на той стороне решить вопрос. Я больше с серверной зайти пытаюсь.
Спасибо, красиво :)
А можете рассказать, почему были выбраны блейд-системы? Дорого ведь, а сэкономить RU цель вряд ли стояла.
И про Эльбрус, если были какие-то намётки, как примерно планировалась миграция? Насколько сильно пришлось бы менять то, что уже построено? Виртуализация там вообще бывает на аппаратном уровне? Какой софт спокойно работает, а какой — не очень? Ну и как хотя бы примерно соотносится цена/производительность с традиционными системами…
Очень интересно послушать человека, который щупал их системы вживую.
А можете рассказать, почему были выбраны блейд-системы? Дорого ведь, а сэкономить RU цель вряд ли стояла.
И про Эльбрус, если были какие-то намётки, как примерно планировалась миграция? Насколько сильно пришлось бы менять то, что уже построено? Виртуализация там вообще бывает на аппаратном уровне? Какой софт спокойно работает, а какой — не очень? Ну и как хотя бы примерно соотносится цена/производительность с традиционными системами…
Очень интересно послушать человека, который щупал их системы вживую.
Вот не могу дать пояснения по поводу Blade-систем, для меня — так исторически сложилось, я пришёл — а они уже есть. Сказать, что они были сильно дороже других систем — тоже не скажу. Для меня, кстати, немаловажным был факт меньших геометрических размеров. Я вообще думал перейти на DELL: они тогда выпустили blade-систему с большей плотностью серверов на юнит.
С использованием Эльбрусов не всё так просто. Я объективно понимал, что поставить их вместо основы для виртуализации не получится никак (кроме как экспериментально и через тернии к звёздам).
Мигрировать я планировал сервисами. Т.к. сами сервисы были кросс-платформенными — нужно было «всего лишь» добиться исполнения на Эльбрусе интересующего окружения. А потом это самое окружение выложить в общий доступ и запустить тем самым волну спроса на отечественную платформу.
На тот момент серверами на базе наших процессоров без особых проблем можно было заполнить нишу, отвечающую за криптографию — это то, что я бы крайне не хотел отдавать виртуализации.
Как сильно пришлось бы менять то, что уже построено? Ровно так же, как переезжать с сервера на Intel под CentOS на AMD под CentOS. Главное — чтобы окружение завелось.
По поводу производительности не хотелось бы делать голословных заявлений… А объективными тестами подкрепить не могу. Под задачу работы ведомственных сервисов Эльбрусы подходили полностью.
С использованием Эльбрусов не всё так просто. Я объективно понимал, что поставить их вместо основы для виртуализации не получится никак (кроме как экспериментально и через тернии к звёздам).
Мигрировать я планировал сервисами. Т.к. сами сервисы были кросс-платформенными — нужно было «всего лишь» добиться исполнения на Эльбрусе интересующего окружения. А потом это самое окружение выложить в общий доступ и запустить тем самым волну спроса на отечественную платформу.
На тот момент серверами на базе наших процессоров без особых проблем можно было заполнить нишу, отвечающую за криптографию — это то, что я бы крайне не хотел отдавать виртуализации.
Как сильно пришлось бы менять то, что уже построено? Ровно так же, как переезжать с сервера на Intel под CentOS на AMD под CentOS. Главное — чтобы окружение завелось.
По поводу производительности не хотелось бы делать голословных заявлений… А объективными тестами подкрепить не могу. Под задачу работы ведомственных сервисов Эльбрусы подходили полностью.
Спасибо за развернутый ответ.
Действительно, сценарий использования для отечественного крипто выглядит логично. С другой стороны, наверное всё же глобальный переезд на такую платформу — это не то же самое, что CentOS под Intel. Где и какая часть отвалится на незнакомом железе никто не скажет заранее. Грабли еще не собраны :) А на интеле можно и вовсе RHEL с поддержкой купить, там все грабли поименно знают. Но такой опыт с Эльбрусом был бы интересный, да…
Действительно, сценарий использования для отечественного крипто выглядит логично. С другой стороны, наверное всё же глобальный переезд на такую платформу — это не то же самое, что CentOS под Intel. Где и какая часть отвалится на незнакомом железе никто не скажет заранее. Грабли еще не собраны :) А на интеле можно и вовсе RHEL с поддержкой купить, там все грабли поименно знают. Но такой опыт с Эльбрусом был бы интересный, да…
Спасибо за отличную статью. Желаю удачи в дальнейшей работе. СПАСИБО!
Какое ПО использовалось для планирования?
Microsoft Visio. Пробовал альтернативные инструменты — не понравилось.
А конкретно те картинки что у вас в статье? Какой-то набор клипартов для MS Visio?
Вендоры бывает сами выкладывают библиотеки своего оборудования для Visio.
Хорошая сборка различного оборудования на сайте VisioCafe.
Хорошая сборка различного оборудования на сайте VisioCafe.
Спасибо за статью, коллега!
«В качестве платформы виртуализации была закуплена — VMWare, на тот момент 5 версии. Тут, думаю, все согласятся, что выбор практически безальтернативен.»
Вот тут не соглашусь. В 2012 году не обязательно было тратить деньги на VMWare (у вас же на потолочный лоток денег не было!), когда можно было обойтись бесплатным Hyper-V Server (2008 R2, а к концу года и 2012), да и SCVMM тогда продавался отдельно от остального SC за относительно смешные деньги.
«В качестве платформы виртуализации была закуплена — VMWare, на тот момент 5 версии. Тут, думаю, все согласятся, что выбор практически безальтернативен.»
Вот тут не соглашусь. В 2012 году не обязательно было тратить деньги на VMWare (у вас же на потолочный лоток денег не было!), когда можно было обойтись бесплатным Hyper-V Server (2008 R2, а к концу года и 2012), да и SCVMM тогда продавался отдельно от остального SC за относительно смешные деньги.
Виртуальные машины от Microsoft на тот момент были сыроваты, того же режима Fault Tolerance не было. Изначально именно поэтому была выбрана vSphere. Сразу скажу, что после тестовых испытаний от работы в режиме Fault Tolerance пришлось отказаться. Те системы, которые были критичны — не могли работать на одном ядре. Хотя в одной из сопровождаемых организаций Hyper-V очень даже выручает, приятный бонус к лицензионной ОС.
Да и назвать его бесплатным язык не поворачивается. Даже при условии покупки Windows 2012 Datacenter с его безлимитными виртуальными лицензиями. Но если сравнивать, например, не версию Standard, а следующие версии — согласен, дешевле. И, опять же, если vSphere спокойно помещалась на USB-flash и отъедала всего ничего ресурсов, то Windows 2012 на хосте требовала для себя уже полноценной дисковой подсистемы в любом её виде, и других ресурсов отъедала побольше.
Вспоминаю свой эксперимент по выделению памяти. Если мне не изменяет память, то меньше чем с 1.5 Гб ОЗУ у меня 2012 винда даже не установилась: вылетала в синий экран. 2008 R2 требовала, порядка 1 Гб, 2003 ставилась и без проблем работала на 512. С одной стороны, конечно, не много. А с другой стороны 512 Мб ОЗУ — это нормальная такая виртуалка под Linux.
Да и назвать его бесплатным язык не поворачивается. Даже при условии покупки Windows 2012 Datacenter с его безлимитными виртуальными лицензиями. Но если сравнивать, например, не версию Standard, а следующие версии — согласен, дешевле. И, опять же, если vSphere спокойно помещалась на USB-flash и отъедала всего ничего ресурсов, то Windows 2012 на хосте требовала для себя уже полноценной дисковой подсистемы в любом её виде, и других ресурсов отъедала побольше.
Вспоминаю свой эксперимент по выделению памяти. Если мне не изменяет память, то меньше чем с 1.5 Гб ОЗУ у меня 2012 винда даже не установилась: вылетала в синий экран. 2008 R2 требовала, порядка 1 Гб, 2003 ставилась и без проблем работала на 512. С одной стороны, конечно, не много. А с другой стороны 512 Мб ОЗУ — это нормальная такая виртуалка под Linux.
Мне хотелось бы услышать/прочитать описание хоть одного реального случая, когда 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 было ошибкой, я лишь не согласен с тем, что оно было «безальтернативным».
Далее, если у вас критический сервис, минутный простой которого во время загрузки на другой ноде кластера недопустим, не имеет режима 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 было ошибкой, я лишь не согласен с тем, что оно было «безальтернативным».
Спасибо за развёрнутый комментарий!
Постараюсь прокомментировать по пунктам:
1. На тестовом стенде Fault Tolerance я тестировал один из хардкорных вариантов: просто физически вынималось работающее лезвие, затем возвращалось. Понятно, что это не самый гуманный способ, но мне нужно было быть уверенным, что система не упадёт. И она не падала. Но это всё была «синтетика», как он себя поведёт в реальной системе — для меня тоже скорее вопрос, чем твёрдая уверенность. И мой мысленный эксперимент также не сулил ничего хорошего для FT.
Как показала практика, минутная пауза на старт системы для пользователей проходила не особо заметно. Все больше грешили на «отсутствие интернета».
2. Да, я имел в виду роль Hyper V.
3. С SAN была ещё одна очень «плавающая» проблема. До какой-то из версий прошивок контроллера, установленного в лезвиях, он сбоил и при перезагрузке не всегда видел назначенные ему LUN. Т.е. после загрузки гипервизора проблем я не помню, а вот на моменте так сказать инициализации BIOS — проблемы были. Это тоже было одним из факторов за перенос гипервизора на локальное хранилище.
4. Я не спорю, что не только VMWare занимались виртуализацией. У Microsoft виртуализация появилась ещё тогда, когда они приобрели Connectix Virtual PC, если мне не изменяет память. Также параллельно развивались VirtualBox, Parallels. Ну т.е. теоретически выбор был.
Но, повторюсь, одной из задач было поднятие FT. Маркетинг или нет — судить не хочу, но у одних FT был, у других нет, альтернативы по функционалу не было. И, в принципе, если бы не кривизна архитектуры ПО и возможность её горизонтально масштабировать — FT как минимум можно было бы запустить в бой. Также было ограничение по поддерживаем Hyper-V гостевым ОС, ESXi поддерживал большее количество гостевых ОС. Я вот сейчас точно не помню, но там было ещё какое-то ограничение на размер образа файловой системы, от которого VMWare избавилось раньше. Что-то было связано со значением в 2Тб, по-моему. Я так понимаю Вы более плотно работаете с Hyper-V, думаю Вы быстрее вспомните все различия того времени.
Доступно свежее сравнение гипервизоров, они идут практически ноздря в ноздрю, но т.к. у VMWare виртуализация — основной вид деятельность, мне кажется, что в частностях они слегка впереди. Но я боюсь, что это зарождается тема для холивара. В итоге я считаю, что нужно выбирать исходя из текущих и планируемых потребностей в каждом случае индивидуально.
5. По поводу «сырости» — Windows 2012 на тот момент только вышел. Если быть точнее, то на момент моего трудоустройства Windows 2012 только ещё планировался к выходу. Проблемы с ОС после выхода были и их было не мало.
Т.е. либо нужно было использовать заведомо устаревший гипервизор от 2008 R2, либо ждать и идти первым по граблям 2012…
6. В плане внедрения Вы меня несколько неправильно поняли. Инициатива появилась после трудоустройства. VMWare мне достался уже как факт на всех лезвиях. Когда приобретался Windows Datacenter — уже было понимание того, что какую-то часть лезвий целесообразно поднять на гипервизоре от Microsoft, хотя бы с точки зрения экономии на лицензиях гипервизоров. А под занавес работ и ESXi бесплатный появился.
Постараюсь прокомментировать по пунктам:
1. На тестовом стенде Fault Tolerance я тестировал один из хардкорных вариантов: просто физически вынималось работающее лезвие, затем возвращалось. Понятно, что это не самый гуманный способ, но мне нужно было быть уверенным, что система не упадёт. И она не падала. Но это всё была «синтетика», как он себя поведёт в реальной системе — для меня тоже скорее вопрос, чем твёрдая уверенность. И мой мысленный эксперимент также не сулил ничего хорошего для FT.
Как показала практика, минутная пауза на старт системы для пользователей проходила не особо заметно. Все больше грешили на «отсутствие интернета».
2. Да, я имел в виду роль Hyper V.
3. С SAN была ещё одна очень «плавающая» проблема. До какой-то из версий прошивок контроллера, установленного в лезвиях, он сбоил и при перезагрузке не всегда видел назначенные ему LUN. Т.е. после загрузки гипервизора проблем я не помню, а вот на моменте так сказать инициализации BIOS — проблемы были. Это тоже было одним из факторов за перенос гипервизора на локальное хранилище.
4. Я не спорю, что не только VMWare занимались виртуализацией. У Microsoft виртуализация появилась ещё тогда, когда они приобрели Connectix Virtual PC, если мне не изменяет память. Также параллельно развивались VirtualBox, Parallels. Ну т.е. теоретически выбор был.
Но, повторюсь, одной из задач было поднятие FT. Маркетинг или нет — судить не хочу, но у одних FT был, у других нет, альтернативы по функционалу не было. И, в принципе, если бы не кривизна архитектуры ПО и возможность её горизонтально масштабировать — FT как минимум можно было бы запустить в бой. Также было ограничение по поддерживаем Hyper-V гостевым ОС, ESXi поддерживал большее количество гостевых ОС. Я вот сейчас точно не помню, но там было ещё какое-то ограничение на размер образа файловой системы, от которого VMWare избавилось раньше. Что-то было связано со значением в 2Тб, по-моему. Я так понимаю Вы более плотно работаете с Hyper-V, думаю Вы быстрее вспомните все различия того времени.
Доступно свежее сравнение гипервизоров, они идут практически ноздря в ноздрю, но т.к. у VMWare виртуализация — основной вид деятельность, мне кажется, что в частностях они слегка впереди. Но я боюсь, что это зарождается тема для холивара. В итоге я считаю, что нужно выбирать исходя из текущих и планируемых потребностей в каждом случае индивидуально.
5. По поводу «сырости» — Windows 2012 на тот момент только вышел. Если быть точнее, то на момент моего трудоустройства Windows 2012 только ещё планировался к выходу. Проблемы с ОС после выхода были и их было не мало.
Т.е. либо нужно было использовать заведомо устаревший гипервизор от 2008 R2, либо ждать и идти первым по граблям 2012…
6. В плане внедрения Вы меня несколько неправильно поняли. Инициатива появилась после трудоустройства. VMWare мне достался уже как факт на всех лезвиях. Когда приобретался Windows Datacenter — уже было понимание того, что какую-то часть лезвий целесообразно поднять на гипервизоре от Microsoft, хотя бы с точки зрения экономии на лицензиях гипервизоров. А под занавес работ и ESXi бесплатный появился.
Спасибо за интересное продолжение диалога!
Сразу оговорюсь, это не холивар, мне интересно сравнить впечатления и обменяться опытом. Я не «не люблю 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 нет, каким образом он применим в описанной архитектуре?
Сразу оговорюсь, это не холивар, мне интересно сравнить впечатления и обменяться опытом. Я не «не люблю 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 нет, каким образом он применим в описанной архитектуре?
Вот я тоже могу рассказать, почему выбирают vmware.
1) Жесткий HCL vs «заведется любая железка, под которую есть драйвер для Win, но грабли ищите сами». Это не значит что на vmware не бывает проблем из-за кривых драйверов, но по меньшей мере, дает какую-то опорную точку для подбора железа. Да и вендоры охотнее проблемы решают, когда их строчка в HCL под угрозой.
2) Patch tuesday на хостах виртуализации каждый месяц, а современные ESXi спокойно работают годами, только и нужно, что следить за серьезными security-заплатками, которых, по-моему, и не было со времен Heartbleed.( и то это только management-интерфейсов касалось.)
3) SCVMM глюкавый и неудобный, и даже меееедленный веб-клиент vsphere в использовании приятнее. По-крайней мере он всё в одну точку сводит, а не так что «это у нас в SCVMM, а за вот тем пожалуйте в cluster manager». Скажете, это личные предпочтения? Найдите хоть одного человека, который в восхищении от SCVMM после vCenter.
4) MS premier support стоит космических денег, поэтому в большинстве случаев конечные пользователи остаются один на один с технетом.
5) В мире vmware по-прежнему основной гипервизор в энтерпрайзе, поэтому иногда hyper-v просто не поддерживают. Есть у нужного веднора только virtual appliance в виде OVF, и всё.
6) Сопутствующие vmware-only технологии, например vSAN и NSX. Знаю, S2D грядет, но пока это будущее.
7) В целом архитектурно vmware красивее. Например, зависимость работы кластера от наличия живого домена — довольно неожиданное ограничение Hyper-V. Всякие disaster сценарии не упрощает. Хотя, что до красоты, внутреннее устройство vcenter или его appliance — тот еще дремучий лес. Но, по-крайней мере, сам ESXi очень лаконичный.
В общем, моё мнение — vmware более цельное и интегрированное решение, система «сама в себе», а hyper-v несет в себе много чисто виндовых запчастей, которые скорее мешают, чем помогают.
При всём при этом ценник на взрослые версии vmware термоядерный, и у них есть ненулевая вероятность лет через пять стать чем-то вроде Oracle DB — вроде бы круто, но мало кто толком объяснит почему, и уж точно вряд ли сможет обосновать стоимость против аналогов. Зато SAP поддерживает! Короче, для больших неповоротливых махровых компаний.
А hyper-v поделят с KVM остальной рынок :)
Хотя, с введением per-core licensing в WS2016 и возвращением функциональных отличий в редакциях всё может вдруг стать не так однозначно…
P.S. А вот с FUDом по поводу нежелания переводить рабочие системы резко на новейший Win Server вы точно погорячились. Кто в здравом уме будет грабли собирать на боевых нагрузках? Тем более, когда речь об ОС — в этом случае и железо тоже должно быть совместимо. А вендоры еще не собрали баги в новых драйверах… Чур меня, чур! Год минимум от релиза. В лабе погонять — другое дело конечно, там и с technical preview начинать можно.
Вот vmware кстати как раз уже год всем демонстрируют с ESXi 6, что проблемных релизов можно ожидать от кого угодно.
1) Жесткий HCL vs «заведется любая железка, под которую есть драйвер для Win, но грабли ищите сами». Это не значит что на vmware не бывает проблем из-за кривых драйверов, но по меньшей мере, дает какую-то опорную точку для подбора железа. Да и вендоры охотнее проблемы решают, когда их строчка в HCL под угрозой.
2) Patch tuesday на хостах виртуализации каждый месяц, а современные ESXi спокойно работают годами, только и нужно, что следить за серьезными security-заплатками, которых, по-моему, и не было со времен Heartbleed.( и то это только management-интерфейсов касалось.)
3) SCVMM глюкавый и неудобный, и даже меееедленный веб-клиент vsphere в использовании приятнее. По-крайней мере он всё в одну точку сводит, а не так что «это у нас в SCVMM, а за вот тем пожалуйте в cluster manager». Скажете, это личные предпочтения? Найдите хоть одного человека, который в восхищении от SCVMM после vCenter.
4) MS premier support стоит космических денег, поэтому в большинстве случаев конечные пользователи остаются один на один с технетом.
5) В мире vmware по-прежнему основной гипервизор в энтерпрайзе, поэтому иногда hyper-v просто не поддерживают. Есть у нужного веднора только virtual appliance в виде OVF, и всё.
6) Сопутствующие vmware-only технологии, например vSAN и NSX. Знаю, S2D грядет, но пока это будущее.
7) В целом архитектурно vmware красивее. Например, зависимость работы кластера от наличия живого домена — довольно неожиданное ограничение Hyper-V. Всякие disaster сценарии не упрощает. Хотя, что до красоты, внутреннее устройство vcenter или его appliance — тот еще дремучий лес. Но, по-крайней мере, сам ESXi очень лаконичный.
В общем, моё мнение — vmware более цельное и интегрированное решение, система «сама в себе», а hyper-v несет в себе много чисто виндовых запчастей, которые скорее мешают, чем помогают.
При всём при этом ценник на взрослые версии vmware термоядерный, и у них есть ненулевая вероятность лет через пять стать чем-то вроде Oracle DB — вроде бы круто, но мало кто толком объяснит почему, и уж точно вряд ли сможет обосновать стоимость против аналогов. Зато SAP поддерживает! Короче, для больших неповоротливых махровых компаний.
А hyper-v поделят с KVM остальной рынок :)
Хотя, с введением per-core licensing в WS2016 и возвращением функциональных отличий в редакциях всё может вдруг стать не так однозначно…
P.S. А вот с FUDом по поводу нежелания переводить рабочие системы резко на новейший Win Server вы точно погорячились. Кто в здравом уме будет грабли собирать на боевых нагрузках? Тем более, когда речь об ОС — в этом случае и железо тоже должно быть совместимо. А вендоры еще не собрали баги в новых драйверах… Чур меня, чур! Год минимум от релиза. В лабе погонять — другое дело конечно, там и с technical preview начинать можно.
Вот vmware кстати как раз уже год всем демонстрируют с ESXi 6, что проблемных релизов можно ожидать от кого угодно.
Не удержусь, прокомментирую по пунктам, хоть, простите, в отличие от автора статьи, ваше сообщение — уже на грани холивара.
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. В условиях миниатюризации и всё большей специализации вычислительных нод я не уверен, что за гиперконвергентностью светлое будущее, но согласен, что наличие функциональности — это плюс. Для кого-то, возможно, это станет решающим фактором. Через несколько месяцев и в этом вопросе будет достигнут паритет.
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. В условиях миниатюризации и всё большей специализации вычислительных нод я не уверен, что за гиперконвергентностью светлое будущее, но согласен, что наличие функциональности — это плюс. Для кого-то, возможно, это станет решающим фактором. Через несколько месяцев и в этом вопросе будет достигнут паритет.
Для продолжения дискуссии хотелось бы для себя кое-что уяснить, и внести правку:
1. Коллега, Вы имеете опыт боевого использования обеих систем виртуализации?
2. У меня имеется опыт использования в бою только VMWare, VirtualBox — дома. На Hyper-V у меня только в одной организации работает одинокая FreeBSD, поэтому я это опытом не считаю.
Сейчас я понимаю, что вызвал бурную реакция словом «безальтернативен», прошу прощения. Я несколько изменил формулировку, чтобы она больше соответствовала действительности.
У меня складывается впечатление, что Вы имеете большой опыт развёртывания систем на базе решения Windows. Либо, если есть опыт работы с обеими системами виртуализации, то тут уж я бы лучше Вас послушал на тему чем одна из них лучше, чем другая.
Я честно скажу, объективно сравнить две системы не могу. Да, я хотел использовать в ЦОД и ту и другую виртуализацию, чтобы можно было в т.ч. объективно рассуждать, но не успел.
По своим субъективным ощущениям, если опустить маркетинговые сравнения, мне VMWare нравится больше потому, что она на Linux. Что мне, в первую очередь, не нравится в Hyper-V? Windows Core.
Нет, я не злобный линуксоид, у меня даже есть сертификаты, что я самый что ни на есть сертифицированный Windows-админ. У меня достаточно большой опыт внедрения и эксплуатации различных систем на различных операционных системах. Я ненавижу настраивать Linux: пока настроишь с ума сойдешь. Но когда всё настроил — он ведёт себя очень предсказуемо. Но также я ненавижу настроенный Windows: обязательно где-то забудешь снять/поставить галочку и система будет себя вести непредсказуемо, пока не найдёшь искомую галочку.
Обновления в обеих ОС — это вообще отдельная песнь льда и пламени: практически в каждой серии или кого-то убьют, или будет секс.
Но давайте не забывать, что и одно и другое — всего лишь инструменты. Поэтому для каждой ситуации решение должно выбираться индивидуально, а не только потому, что «раз я это знаю, значит этим и надо пользоваться». Хотя часто бывает, что и эта причина ставится во главу угла: смысл специалиста по windows заставлять сопровождать *nix и наоборот? если уж в компании есть хороший windows-админ, то лучше ему давать те инструменты, которыми он владеет в совершенстве, а не подставлять и потом говорить «тыжпрограммист!», когда что-то упало.
Лично мне на тот момент и сейчас было бы абсолютно всё равно на чём поднимать виртуализацию: VMWare или Hyper-V. У заказчика-работодателя был на тот момент приобретён VMWare, его нужно было заставить работать, я это и сделал. Если бы системы виртуализации не было — выбор, ввиду долгих конкурсных процедур и т.п., однозначно пал бы на любое бесплатное решение, но и тут выбор был бы необъективен, а навязан финансово-временными рамками.
Если бы у меня действительно была возможность выбирать, я бы пошёл по пути снижения вероятности выхода из строя по причине виртуализации и внедрил бы сразу две системы виртуализации (всё равно какие, лишь бы две, максимально непохожие друг на друга). И разделил бы резервируемые сервисы между ними (например, основной и резервный контроллеры домена). Чтобы если уж вдруг, в какой-то момент времени произойдёт какая-то неисправность (ошибка программиста ВМ, внешняя атака, ошибка администратора...) в одной системе виртуализации — вторая осталась работать. Но это, мне кажется, идеальный случай.
1. Коллега, Вы имеете опыт боевого использования обеих систем виртуализации?
2. У меня имеется опыт использования в бою только VMWare, VirtualBox — дома. На Hyper-V у меня только в одной организации работает одинокая FreeBSD, поэтому я это опытом не считаю.
Сейчас я понимаю, что вызвал бурную реакция словом «безальтернативен», прошу прощения. Я несколько изменил формулировку, чтобы она больше соответствовала действительности.
У меня складывается впечатление, что Вы имеете большой опыт развёртывания систем на базе решения Windows. Либо, если есть опыт работы с обеими системами виртуализации, то тут уж я бы лучше Вас послушал на тему чем одна из них лучше, чем другая.
Я честно скажу, объективно сравнить две системы не могу. Да, я хотел использовать в ЦОД и ту и другую виртуализацию, чтобы можно было в т.ч. объективно рассуждать, но не успел.
По своим субъективным ощущениям, если опустить маркетинговые сравнения, мне VMWare нравится больше потому, что она на Linux. Что мне, в первую очередь, не нравится в Hyper-V? Windows Core.
Нет, я не злобный линуксоид, у меня даже есть сертификаты, что я самый что ни на есть сертифицированный Windows-админ. У меня достаточно большой опыт внедрения и эксплуатации различных систем на различных операционных системах. Я ненавижу настраивать Linux: пока настроишь с ума сойдешь. Но когда всё настроил — он ведёт себя очень предсказуемо. Но также я ненавижу настроенный Windows: обязательно где-то забудешь снять/поставить галочку и система будет себя вести непредсказуемо, пока не найдёшь искомую галочку.
Обновления в обеих ОС — это вообще отдельная песнь льда и пламени: практически в каждой серии или кого-то убьют, или будет секс.
Но давайте не забывать, что и одно и другое — всего лишь инструменты. Поэтому для каждой ситуации решение должно выбираться индивидуально, а не только потому, что «раз я это знаю, значит этим и надо пользоваться». Хотя часто бывает, что и эта причина ставится во главу угла: смысл специалиста по windows заставлять сопровождать *nix и наоборот? если уж в компании есть хороший windows-админ, то лучше ему давать те инструменты, которыми он владеет в совершенстве, а не подставлять и потом говорить «тыжпрограммист!», когда что-то упало.
Лично мне на тот момент и сейчас было бы абсолютно всё равно на чём поднимать виртуализацию: VMWare или Hyper-V. У заказчика-работодателя был на тот момент приобретён 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, которой следует избегать любой ценой.
Решения на базе 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, которой следует избегать любой ценой.
Не холивара ради, а истины для:
1) Не совсем так, проблема в отсутствии HCL, а не в наличии драйвера. HCL — подмножество всего железа, имеющего драйверы.
2) Не спорю, но возможны разные сценарии. Сетевые свитчи, например, никто не обновляет каждый месяц, хотя там тоже и кластеры, и rolling upgrade, и все такое — изменения могут внести проблемы, а зачем это нужно, если и так всё хорошо? Обновления ради обновлений — не совсем правильный подход, по-моему.
3) Не во фломастерах ведь дело, а в том, что hyper-v manager, FCL manager и SCVMM имеют непересекающиеся функции, и работать приходится со всеми тремя. И это шаг назад после vcenter, как минимум.
4) SA support совсем грустный по моему опыту — продраться сквозь начальных индусов к инженерам — подвиг. И телефонной поддержки нет. Но согласен, выбор это лучше, чем его отсутствие.
5) Нет, к сожалению, статистики нет, это мой личный опыт. Как пример — почти всё что делает Cisco, не поддерживает Hyper-V. Обратные примеры мне не попадались. Можете сказать что личный опыт — это не аргумент, но мы же начинали с вопроса, «почему кто-то покупает vmware?», а не «кто сильнее, слон или кит?».
6) Сразу скажу, я не щупал NSX, но насколько я это понимаю, то что есть в SCVMM ближе к vDS, и куда проще. Не просто так они столько денег за NSX просят.
7) Холиварный пункт, не хочу развивать. Мне кажется, виртуализация слишком специфическая, чтобы сильно выигрывать от интеграции с экосистемой, вам так не кажется. Давайте останемся «при своих».
Да, лицензирование Win Server — отдельная история от гипервизора, я знаю. Вот как сравнивать с vmware, так всё бесплатно, а как поддержка, так везде Software Assurance должна быть! :)
А вообще просто лично меня задели сильно эти изменения, простите, не удержался. Кстати, S2D будет только в старшей редакции.
Поймите правильно, я просто предлагаю взгляд со стороны. И хочу сказать, что и за vmware, и за Hyper-V есть аргументы. Иначе, наверное, vmware бы уже прекратила существование.
1) Не совсем так, проблема в отсутствии HCL, а не в наличии драйвера. HCL — подмножество всего железа, имеющего драйверы.
2) Не спорю, но возможны разные сценарии. Сетевые свитчи, например, никто не обновляет каждый месяц, хотя там тоже и кластеры, и rolling upgrade, и все такое — изменения могут внести проблемы, а зачем это нужно, если и так всё хорошо? Обновления ради обновлений — не совсем правильный подход, по-моему.
3) Не во фломастерах ведь дело, а в том, что hyper-v manager, FCL manager и SCVMM имеют непересекающиеся функции, и работать приходится со всеми тремя. И это шаг назад после vcenter, как минимум.
4) SA support совсем грустный по моему опыту — продраться сквозь начальных индусов к инженерам — подвиг. И телефонной поддержки нет. Но согласен, выбор это лучше, чем его отсутствие.
5) Нет, к сожалению, статистики нет, это мой личный опыт. Как пример — почти всё что делает Cisco, не поддерживает Hyper-V. Обратные примеры мне не попадались. Можете сказать что личный опыт — это не аргумент, но мы же начинали с вопроса, «почему кто-то покупает vmware?», а не «кто сильнее, слон или кит?».
6) Сразу скажу, я не щупал NSX, но насколько я это понимаю, то что есть в SCVMM ближе к vDS, и куда проще. Не просто так они столько денег за NSX просят.
7) Холиварный пункт, не хочу развивать. Мне кажется, виртуализация слишком специфическая, чтобы сильно выигрывать от интеграции с экосистемой, вам так не кажется. Давайте останемся «при своих».
Да, лицензирование Win Server — отдельная история от гипервизора, я знаю. Вот как сравнивать с vmware, так всё бесплатно, а как поддержка, так везде Software Assurance должна быть! :)
А вообще просто лично меня задели сильно эти изменения, простите, не удержался. Кстати, S2D будет только в старшей редакции.
Поймите правильно, я просто предлагаю взгляд со стороны. И хочу сказать, что и за vmware, и за Hyper-V есть аргументы. Иначе, наверное, 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 последних лет не имели под собой никакого фактического обоснования.
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 последних лет не имели под собой никакого фактического обоснования.
1. Согласен, есть WHC. Тем не менее, я считаю, что Windows может выполнять столько разных функций, что на совместимость именно с Hyper-V у ведоров упор значительно меньше. Можно, конечно, сказать, что зато и пользователей каких-нибудь сетевых драйверов на Windows гораздо больше и баги выявятся раньше…
И всё же, HCL именно для Hyper-V был бы плюсом.
2. Я к числу авторов PCI DSS не отношусь, поэтому спорить со стандартом не буду. Тем не менее, стандарты пишутся так, чтобы охватить (и в данном случае защитить) большое количество самых разных окружений, поэтому в частном случае требования могут быть избыточны. Я считаю, что при должной оценке рисков можно и нужно строить безопасность так, как этого требует конкретная ситуация. Впрочем, против compliance не попрешь, но это не у всех.
Как бы то ни было, патчей у vmware выходит в разы меньше, и еще меньше относится к безопасности.
3. Нет, но консоли-то у Hyper-V три! И все относятся только к виртуализации, кроме, разве что, FCM.
Powershell — согласен, сам большой поклонник MSовского подхода к CLI.
У vmware, кстати, тоже powerCLI есть, хотя лично мне и не всё нравится, как там организовано.
5. Ну вот, например: «VMware vSphere ESXi is mandatory for all virtualized deployments of Cisco Collaboration.» То есть даже если и удастся запустить CUCM на другом гипервизоре, поддержка помашет ручкой.
Касательно маркетинга — я соглашусь, vmware во многом сильна именно им. Пункт 5 относится туда же, кстати.
Но вот насчет того, что Hyper-V не требует подготовки в отличие от vmware я ну никак согласиться не могу.
На базовом уровне и то и то влёт осваивается до состояния «сервер с парой работающих виртуалок». Hyper-V, пожалуй, на полшага проще, т.к. поставить Win Server уже понятно как, роль в списке уже есть, а оснастка и модуль powershell входят в RSAT.
Вместе с тем, установка vmware сводится к загрузке с ISO и ответу на пяток вопросов вида «на какой раздел будем ставить» и «введите пароль администратора». После этого сетевые настройки прямо перед носом, клиент для управления качается при попытке зайти на ip-адрес новоявленного ESXi хоста, и дальше создать и запустить ВМ ну никак не сложнее чем в Hyper-V.
Что же касается более сложных задач, то и к Hyper-V, и к vmware подходить без специфических знаний будет очень нелегко, и для работающего окружения — попросту опасно. Потому что нужно понимать, как виртуализация работает, а не запоминать где какая кнопка. И ну никак в этом случае тот факт, что оснастка VMM входит в уже знакомые RSAT, не релевантен.
В моём понимании, как и с Windows Phone (ну не настолько, конечно), Hyper-V не хватает не столько технических возможностей, сколько поддержки рынка. Это тот самый пункт 5. А еще это куча статей и прочего fan fiction от посторонних специалистов, такого как исследования производительности, гайды а-ля «точечная настройка хоста для realtime приложений», готовые ответы на вопрос «Ошибка 0x0000BAD, что делать?», и полчища индусов в саппорте самых разных вендоров железа и софта, которые знают ответ на 10 вопросов по Hyper-V и на 100 по vmware, просто в силу того, что их задают чаще.
Как я уже сказал, в данный момент vmware сами себя загоняют в угол с помощью ценовой политики, но если ситуация хоть немного выравняется, MS понадобятся очень убедительные технические доводы в свою пользу помимо «у нас всё то же самое но несколько дешевле», чтобы развернуть неповоротливый рынок. Кстати, против KVM они бы тоже пригодились.
И всё же, HCL именно для Hyper-V был бы плюсом.
2. Я к числу авторов PCI DSS не отношусь, поэтому спорить со стандартом не буду. Тем не менее, стандарты пишутся так, чтобы охватить (и в данном случае защитить) большое количество самых разных окружений, поэтому в частном случае требования могут быть избыточны. Я считаю, что при должной оценке рисков можно и нужно строить безопасность так, как этого требует конкретная ситуация. Впрочем, против compliance не попрешь, но это не у всех.
Как бы то ни было, патчей у vmware выходит в разы меньше, и еще меньше относится к безопасности.
3. Нет, но консоли-то у Hyper-V три! И все относятся только к виртуализации, кроме, разве что, FCM.
Powershell — согласен, сам большой поклонник MSовского подхода к CLI.
У vmware, кстати, тоже powerCLI есть, хотя лично мне и не всё нравится, как там организовано.
5. Ну вот, например: «VMware vSphere ESXi is mandatory for all virtualized deployments of Cisco Collaboration.» То есть даже если и удастся запустить CUCM на другом гипервизоре, поддержка помашет ручкой.
Касательно маркетинга — я соглашусь, vmware во многом сильна именно им. Пункт 5 относится туда же, кстати.
Но вот насчет того, что Hyper-V не требует подготовки в отличие от vmware я ну никак согласиться не могу.
На базовом уровне и то и то влёт осваивается до состояния «сервер с парой работающих виртуалок». Hyper-V, пожалуй, на полшага проще, т.к. поставить Win Server уже понятно как, роль в списке уже есть, а оснастка и модуль powershell входят в RSAT.
Вместе с тем, установка vmware сводится к загрузке с ISO и ответу на пяток вопросов вида «на какой раздел будем ставить» и «введите пароль администратора». После этого сетевые настройки прямо перед носом, клиент для управления качается при попытке зайти на ip-адрес новоявленного ESXi хоста, и дальше создать и запустить ВМ ну никак не сложнее чем в Hyper-V.
Что же касается более сложных задач, то и к Hyper-V, и к vmware подходить без специфических знаний будет очень нелегко, и для работающего окружения — попросту опасно. Потому что нужно понимать, как виртуализация работает, а не запоминать где какая кнопка. И ну никак в этом случае тот факт, что оснастка VMM входит в уже знакомые RSAT, не релевантен.
В моём понимании, как и с Windows Phone (ну не настолько, конечно), Hyper-V не хватает не столько технических возможностей, сколько поддержки рынка. Это тот самый пункт 5. А еще это куча статей и прочего fan fiction от посторонних специалистов, такого как исследования производительности, гайды а-ля «точечная настройка хоста для realtime приложений», готовые ответы на вопрос «Ошибка 0x0000BAD, что делать?», и полчища индусов в саппорте самых разных вендоров железа и софта, которые знают ответ на 10 вопросов по Hyper-V и на 100 по vmware, просто в силу того, что их задают чаще.
Как я уже сказал, в данный момент vmware сами себя загоняют в угол с помощью ценовой политики, но если ситуация хоть немного выравняется, MS понадобятся очень убедительные технические доводы в свою пользу помимо «у нас всё то же самое но несколько дешевле», чтобы развернуть неповоротливый рынок. Кстати, против KVM они бы тоже пригодились.
Не место красит человека, а скромность красит человека!
П.С. За решение установить USB-flash с образом VMWare отдельное спасибо, когда флешки стали дохнуть по очереди и отваливаться лезвия мы Вас вспоминали)
П.С. За решение установить USB-flash с образом VMWare отдельное спасибо, когда флешки стали дохнуть по очереди и отваливаться лезвия мы Вас вспоминали)
Всегда пожалуйста =)
Я так понимаю Вы — сотрудник, пришедший уже сильно после меня? Могу Вам рассказать секрет. Изначально планировалось использовать промышленную Flash-память, но денег на неё не было (и не смотрите так на меня, я помню те времена, когда у нас было оборудования на много миллионов рублей, а оптических патч-кордов чтобы его соединить я ждал 2 месяца), поэтому пришлось устанавливать бытовые накопители. Срок службы бытового накопителя — ограничен. Поэтому планировалось делать ПЛАНОВУЮ замену не реже, чем раз в 1.5 года, либо планово перейти на промышленную память.
Боюсь спросить, что случилось раньше: плановая замена или они вышли из строя, а потом была внеплановая замена? =)
У нас и жёсткие диски в полках отказывали (кстати на одном из фото в статье виден отказавший жёсткий диск в одной из полок), за что, я надеюсь, вы мне тоже благодарны? =)
Я так понимаю Вы — сотрудник, пришедший уже сильно после меня? Могу Вам рассказать секрет. Изначально планировалось использовать промышленную Flash-память, но денег на неё не было (и не смотрите так на меня, я помню те времена, когда у нас было оборудования на много миллионов рублей, а оптических патч-кордов чтобы его соединить я ждал 2 месяца), поэтому пришлось устанавливать бытовые накопители. Срок службы бытового накопителя — ограничен. Поэтому планировалось делать ПЛАНОВУЮ замену не реже, чем раз в 1.5 года, либо планово перейти на промышленную память.
Боюсь спросить, что случилось раньше: плановая замена или они вышли из строя, а потом была внеплановая замена? =)
У нас и жёсткие диски в полках отказывали (кстати на одном из фото в статье виден отказавший жёсткий диск в одной из полок), за что, я надеюсь, вы мне тоже благодарны? =)
Да только жесткие диски были собраны в RAID и отказ одного диска в полке это штатная ситуация. А USB-flash (бытовая) единственная!!! (на лезвие) установленная в единственный USB-разъем лезвия это уже проблема.
Но если мы вернемся в IBM Redbook вышеописанному http://public.dhe.ibm.com/systems/support/system_x_pdf/00d9283.pdf стр.43 то USB-разъем должен использоваться для установки “USB Flash Key”.
Но если мы вернемся в IBM Redbook вышеописанному http://public.dhe.ibm.com/systems/support/system_x_pdf/00d9283.pdf стр.43 то USB-разъем должен использоваться для установки “USB Flash Key”.
Спасибо за комментарий!
Лезвия были собраны в отказоустойчивый кластер. Ваш ответ я понимаю так, что плановая замена не была выполнена, вследствие чего выход из строя был неприятным сюрпризом. К моменту моего ухода как минимум часть накопителей работала уже почти год, соответственно их нужно было менять. Я сожалею, что вы попали в такую ситуацию, но не считаю не выполнение плановых мероприятий ошибкой архитектора.
Коллега, Вы перевели «USB Flash Key» дословно, а это не совсем корректно и из-за этого у Вас случилось недопонимание. Не я первый придумал установить гипервизор на USB, и IBM разделяет со мной мысль об установке гипервизора на «USB память ключ». И даже предлагает «ключи» с предустановленным гипервизором за деньги. Прошу прощения, если мы с IBM оказались не правы.
Лезвия были собраны в отказоустойчивый кластер. Ваш ответ я понимаю так, что плановая замена не была выполнена, вследствие чего выход из строя был неприятным сюрпризом. К моменту моего ухода как минимум часть накопителей работала уже почти год, соответственно их нужно было менять. Я сожалею, что вы попали в такую ситуацию, но не считаю не выполнение плановых мероприятий ошибкой архитектора.
Коллега, Вы перевели «USB Flash Key» дословно, а это не совсем корректно и из-за этого у Вас случилось недопонимание. Не я первый придумал установить гипервизор на USB, и IBM разделяет со мной мысль об установке гипервизора на «USB память ключ». И даже предлагает «ключи» с предустановленным гипервизором за деньги. Прошу прощения, если мы с IBM оказались не правы.
А каким способом был реализован отказоустойчивый кластер, если вы говорите выше что «Сразу скажу, что после тестовых испытаний от работы в режиме Fault Tolerance пришлось отказаться. Те системы, которые были критичны — не могли работать на одном ядре.»?
Добавлю ещё один аргумент против VMware — необходимо, чтобы ваши приемники тоже хорошо знали VMware. Как видите, это не всегда возможно, особенно с учётом специфики гос. предприятий. Вероятность того, что приемники будут разбираться в Windows Server, значительно выше.
Полностью согласен. Обычно именно по этой причине стараюсь делать выбор в пользу Windows-решений. Всё-таки они более user friendly…
Но тут-то я делал систему что называется «для себя», а меня вмварью не запугать =)
Я вообще рассчитывал задержаться в этой организации, т.к. нереализованных идей была масса…
Но тут-то я делал систему что называется «для себя», а меня вмварью не запугать =)
Я вообще рассчитывал задержаться в этой организации, т.к. нереализованных идей была масса…
А я вот не очень согласен. Главное понимать как оно на самом деле работает — почему снэпшот не бэкап, почему кластер — это не значит что у вас никогда ничего не сломается, что будет если LUN отвалится на хранилище во время работы ВМ, ну и прочее. И тут навыки настройки файлового сервера на Win или администрирования AD мало чем помогут.
Лучше уж пусть не думают что «разбираются»… А так что vmware, что hyper-v — тоже GUI, тоже все подписано, и тоже вся документация под рукой.
Лучше уж пусть не думают что «разбираются»… А так что vmware, что hyper-v — тоже GUI, тоже все подписано, и тоже вся документация под рукой.
Навыки настройки файлового сервера помогут самым прямым образом — вместо всех этих 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, где всё подписано».
И навыки администрирования AD/GPO пригодятся, и PowerShell, и mmc, и подсистема Event-ов, включая возможность централизованного сбора, и Failover Cluster Manager, и Windows Firewall с IPSEC, и Performance Monitor и другие средства мониторинга — это просто Windows Server с полутора ролями. Человек со знанием Windows Server сможет администрировать Hyper-V сервера значительно за пределами «GUI, где всё подписано».
А вот здесь я не соглашусь.
Это уже скорее исторически сложившийся миф, когда порог вхождения в win был много ниже, чем в *nix.
Тот же HA кластер на винде не сильно прощем vmware'ного, а местами может даже и сложнее из-за некоторых неявных вещей, так что в случае возникновения проблем у приемника может оказаться много больше головной боли, чем если бы это был vmware.
Как сказали выше, обычные навыки " я умею в файловые шары и поставить ад на виртуалке" тут не помогут.
Документации сейчас немало для освоения, поэтому в автральном режиме, когда что-то упало, тратить время на ознакомление с ней — это достаточно непрофессионально.
Вероятность того, что приемники будут разбираться в Windows Server, значительно выше.
Это уже скорее исторически сложившийся миф, когда порог вхождения в win был много ниже, чем в *nix.
Тот же HA кластер на винде не сильно прощем vmware'ного, а местами может даже и сложнее из-за некоторых неявных вещей, так что в случае возникновения проблем у приемника может оказаться много больше головной боли, чем если бы это был vmware.
Как сказали выше, обычные навыки " я умею в файловые шары и поставить ад на виртуалке" тут не помогут.
Документации сейчас немало для освоения, поэтому в автральном режиме, когда что-то упало, тратить время на ознакомление с ней — это достаточно непрофессионально.
Коллеги, мне кажется, вы спорите о различных специалистах. Оставим на минуту то, что написано в дипломе и условно разделим специалистов на техников и инженеров.
Коллега прав, техника с поверхностным знанием Windows найти гораздо проще, чем со знанием Linux. Но и другой коллега прав, техник вполне успешно может совершать 90% работы по обслуживанию той или иной системы: он «знает» (скорее помнит), где нужно поставить галочку, какой провод выдернуть/вставить, на какую кнопку нажать, какой узел «планово» перезагрузить, «сделать файловую шару»,«поставить ад на виртуалке» и т.д., на этом моменте его и начинают путать с инженером.
Инженер же обладает глубинными познаниями о том КАК работают те или иные технологии. Инженер может не знать какую именно галочку нужно поставить в Windows, или какую команду выполнить в Linux, или что написать на оборудовании Cisco, чтобы обеспечить физическое резервирование и увеличение пропускной способности. Как оно будет называться (nic teaming, bonding, lacp...) — не важно, он знает КАК работает эта технология, поэтому уже через пару минут чтения документации «по ключевым словам» он уже втыкает провода в циску и, тихонько ругаясь, что-то непонятное пишет сначала в одной консоли, затем в другой.
Поэтому поднимать HA-кластер, планировать структуру AD, разворачивать сеть и т.д. должен специалист уровня инженер, лучше — системный инженер (т.к. он видит более общую картину). Техник же тоже может без особых проблем поднять кластер HA: по инструкции (вероятнее всего написанной инженером). И всем будет казаться: зачем нужен высокооплачиваемый инженер, если есть низкооплачиваемые «инженеры», которые делают то же самое.
И на этом моменте не надо путать смену одного инженера другим и смену инженера бюджетным «инженером»-техником.
Коллега прав, техника с поверхностным знанием Windows найти гораздо проще, чем со знанием Linux. Но и другой коллега прав, техник вполне успешно может совершать 90% работы по обслуживанию той или иной системы: он «знает» (скорее помнит), где нужно поставить галочку, какой провод выдернуть/вставить, на какую кнопку нажать, какой узел «планово» перезагрузить, «сделать файловую шару»,«поставить ад на виртуалке» и т.д., на этом моменте его и начинают путать с инженером.
Инженер же обладает глубинными познаниями о том КАК работают те или иные технологии. Инженер может не знать какую именно галочку нужно поставить в Windows, или какую команду выполнить в Linux, или что написать на оборудовании Cisco, чтобы обеспечить физическое резервирование и увеличение пропускной способности. Как оно будет называться (nic teaming, bonding, lacp...) — не важно, он знает КАК работает эта технология, поэтому уже через пару минут чтения документации «по ключевым словам» он уже втыкает провода в циску и, тихонько ругаясь, что-то непонятное пишет сначала в одной консоли, затем в другой.
Поэтому поднимать HA-кластер, планировать структуру AD, разворачивать сеть и т.д. должен специалист уровня инженер, лучше — системный инженер (т.к. он видит более общую картину). Техник же тоже может без особых проблем поднять кластер HA: по инструкции (вероятнее всего написанной инженером). И всем будет казаться: зачем нужен высокооплачиваемый инженер, если есть низкооплачиваемые «инженеры», которые делают то же самое.
И на этом моменте не надо путать смену одного инженера другим и смену инженера бюджетным «инженером»-техником.
Вы правильно описали универсального (пост-)советского инженера. Мне кажется, такие специалисты достаточно редки даже в ваших краях, не говоря уже о моей стороне глобуса, где предпочитают специализацию. Они ценны на этапе проектирования и создания инфраструктуры, но на этапе поддержки и планового развития в них уже нет необходимости. Такие специалисты достаточно дороги, чтобы держать их просто для поддержки, если вы не интегратор. Вот тут на сцену и выходит условный младший инженер в пост-советской терминологии (или Server technician/associate, не путать с Desktop technician, который как раз техник). В общем, не важно как он называется, но вероятность того, что он сможет, скажем, посмотреть Events на Hyper-V сервере, достаточно высока, а для VMware уже нужно нанимать специалиста по VMware.
Ещё раз по поводу загрузки с 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 возможности за новейшие прогрессивные технологии, которые вы и попытались внедрить?
Сейчас, в основном, от этого даже OEM отказались в пользу SATA DOM, которые втыкаются прямо в разъём на материнской плате и собираются в стандартный RAID1 силами SATA-контроллера.
Если можно, вопрос: блейд-системы IBM уже были до вас. Поскольку дисков в самих лезвиях не было, как производилась загрузка — с SAN? По какой причине было принято решение отказаться от штатного режима загрузки и использовать вместо отказоустойчивой SAN бытовые USB флешки?
Я почему спрашиваю: не примите на свой счёт, просто вы перечислили все «selling points» VMware vs. Hyper-V из методички продавцов VMware. С вами, случайно, поставщик решений VMware не общался на этапе принятия решений? Я не намекаю ни на какую коррупцию, я имею в виду, не ввели ли вас в заблуждение, выдав спорные, но уникальные для VMware возможности за новейшие прогрессивные технологии, которые вы и попытались внедрить?
Да, загрузка производилась с SAN, но с ней были проблемы, в т.ч. программно-аппаратные. Плюс это дало разделение выполнения и данных, что упростило и ускорило процесс поиска неисправностей.
Обладай я неограниченным ресурсом, стал бы я снова ставить гипервизор на флешки? Не думаю. Стал бы смешивать исполнение и данные? Не хотелось бы, но ситуации бывают разные.
Нет, со мной поставщики решений VMWare не общались, решение было принято до меня. =)
Не понимаю, почему у Вас желание сделать отказоустойчивый кластер вызывает такую негативную реакцию? Вы не считаете, что отказоустойчивость нод кластера для важных систем — это хорошо? Понятное дело, что стоит вопрос в реализации… Но всё же?
Обладай я неограниченным ресурсом, стал бы я снова ставить гипервизор на флешки? Не думаю. Стал бы смешивать исполнение и данные? Не хотелось бы, но ситуации бывают разные.
Нет, со мной поставщики решений VMWare не общались, решение было принято до меня. =)
Не понимаю, почему у Вас желание сделать отказоустойчивый кластер вызывает такую негативную реакцию? Вы не считаете, что отказоустойчивость нод кластера для важных систем — это хорошо? Понятное дело, что стоит вопрос в реализации… Но всё же?
Я понял! Вы просто не любите VMWare! =)
Так это же просто инструмент! Здесь он был применён из-за возможностей Fault Tolerance. То, что желаемое разошлось с действительностью — проблема скорее архитектуры приложения, чем VMWare. Но при некоторой доработке архитектуры приложения напильником его всё-таки можно использовать. А аналога у Hyper-V по-прежнему нет =)
Так это же просто инструмент! Здесь он был применён из-за возможностей Fault Tolerance. То, что желаемое разошлось с действительностью — проблема скорее архитектуры приложения, чем VMWare. Но при некоторой доработке архитектуры приложения напильником его всё-таки можно использовать. А аналога у Hyper-V по-прежнему нет =)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как создавался региональный государственный ЦОД