Да не парьтесь вы, найдутся, видимо, на хабре и те, кому такие статьи будут очень полезны. Человек начал осваивать Hyper-V, хочет поделиться своей радостью с миром. Пусть делится, жалко, что ли?
Человек показывает другим как правильно готовить Hyper-V.
Так сказать облегчает им путь освоения технологии. :)
Впрочем, когда я писал про инфраструктуру на Unix/Linux тоже были те кому все понятно и известно. Одно мне не ясно, что их так тянет в мои топики? Самоутвердится хочется?
Хочется выразить недоумение в адрес копипасты с вашего блога на технете. Это запрещено правилами Хабра. Также хочется выразить сомнение в необходимости таких вот «обзорных» топиков. Выглядят они как инструкции для обезьянки с картинками. Соли маловато и перца не хватает.
Самоутвердиться, очевидно, хочется вам, но как-то способ выбран странный.
Считаете этот материали недостаточно глубоким для своего взыскательного вкуса. Отлично я не против продолжайте считать так дальше. Только определитесь уже как нибудь со своим мнением окончательно а то вас трудно понять:
> Да не парьтесь вы, найдутся, видимо, на хабре и те, кому такие статьи будут очень полезны
> Также хочется выразить сомнение в необходимости таких вот «обзорных» топиков.
Про качество топиков которые публикуете вы я скромно промолчу. Это ведь тоже кладезь информации обзорного характера.
Эти топики для кого? Тоже для «обезъянок» только с Android?
Тем не менее я не считаю себя вправе приходить в ваши топики и писать комменты в стиле «что за ерунда». Раз вас читают значит кому то это нужно.
Мое мнение что профессионалами не рождаются поэтому те кого вы сегодня назвали «обезъянками» через некоторое время станут специалистами и понятные подробные иструкции весьма облегчат им жизнь.
Вы еще и сарказм не различаете. Ну прямо Шелдон.
Указанные вами топики — новостные. Ничего необычного. Я не пытаюсь самореализоваться на хабре, я вообще его воспринимаю скорее как аггрегатор ИТ-новостей и околоайтишной информации. Иногда проскакивают и годные авторские топики.
Приходите в мои топики и пишете что угодно. Для этого и пишутся публичные топики.
«Профессионалы», обучающиеся на комиксах никогда не ими станут. Это мое ИМХО. Пока своими собственными руками и мозгами не расковыряешь до дна интересующую тебя технологию — будешь эникеем и обезьянкой.
Чтобы начать что то ковырять руками и понять как оно работает обычно люди начинают с чтения учебника. Часто в нем бывают картинки и инструкции вероятно это как раз для «обезъянок» написано.
Если технология заработала с ней начинают разбираться уже более детально и только потом становятся специалистами в ней.
Данный топик лишь короткая инструкция для начала изучения и proof of concept для тех кто просто интересуется гипотетической возможностью миграции SCO OpenServer под Hyper-V.
>Кстати, коммент на который вы отвечаете — детектор своего рода. Палитесь, товарищ.
У меня такое ощущение, что вы ведете внутренний диалог сам с собой. Пытаетесь доказать, что вот мы тут все не правы. Может вы не в курсе, что это глупо? Потому как, когда мне в свое время требовалась помощь что-то понять и разобраться, то вопросы на форумах тематических и т.п. пересылались в гугл, вот такими же зазнайками, как вы.
Куда не посмотришь везде творчество, превыше всего. Вы не разработчик часом? :)
А сделать стабильно работающую и поддерживаемую вендором конфигурацию инфраструктуры, которая будет обслуживать миллионы абонентов это конечно не творчество, потому как по мануалам, гайдам и прочим лучшим практикам сделано. :)
У Фурсенко к сожалению сфера деятельности другая. То что ему точные науки не нужны не означает что любой инженер сможет всю жизнь выезжать не креативности.
Боюсь представить что будет если инженеры в машиностроении начнут раз за разом подходить к тех. процессу изготовления продукции креативненько. :)
на самом деле из топика я не узнал, как правильно готовить Hyper-V, но узнал, что sco жив и будет жить еще долго, и его вполне можно виртуализировать с помощью Hyper-V(ксати, при помощи VMware тоже можно как пишут здесь)
Ммммм… Предложение про прокачку пары HD-фильмов через самбу я прочитал.
Что-то я не вижу здесь тестов виртуального процессора, если уж используется банком то процессинговые сервисы как раз процессор нагружать и будут.
Не вижу тестов стабильности NFS, который все нормальные люди используют, чтобы шарить дисковое пространство между серверами.
Не вижу тестов комбинированного ПО, которое задействует сетевую и дисковую подсистемы.
Не вижу тестов того, как сетевая подсистема ведёт себя, когда на сервер долбится 100 конкурентных подключений.
Не статьями едиными. Ведь есть куча других применений. Например проталкивать нужные и низводить ненужные публикации, приглашать других евангелистов Microsoft на Хабр…
Честно говоря низводить чьи бы то ни было публикации не вижу смысла. На каждый товар будет купец. Слишком по детски бороться неизвестно с кем в интернете.
Если вы не в курсе у Microsoft здесь платный блог как и у других коммерческих компаний. Это означает что мы можем практически не переживать ни о своей ни о чужой карме.
Я пишу в блог Виртуализация потому что освещаемая тема более узка. Хотя спокойно мог бы постить без оглядки на карму в официальный блог сколько влезет.
Поддержкой гостевых ОС, драйверами. Особенностями кластеризации. Тем как реализовывать резервное копирование виртуальных сред. Как делать их массовое развертывание. Как проводить мониторинг.
Я как раз ждал когда в топик примчатся ненавистники SCO. :)
Видно для вас термин стоимость миграции ничего не говорит?
Кто даст денег на революцию во имя идеи свободного ПО в рамках одной компании с переписыванием всего того ПО что работает сейчас на SCO?
Сколько будет длиться проект миграции? Сколько будет стоить переобучение персонала?
Риски от прерывания бизнес процесса вы считали? Готовы риснуть работой крупного банка?
Почему то немецкие банки не спешат переходить с OS/2 на что то новое, а используюют ее до сих пор под эмуляцией. Видимо их в первую очередь интересует экономия бюджета, а не борьба за светлые идеи свободы во всем мире.
Я тоже не в восторге от поведения SCO за последние годы, но экономические вопросы выгоды и затрат на ИТ обслуживание предпочитаю держать отдельно от идеологии. Посему смотрю на вопрос сугубо прагматично.
А VMWare перестал быть проприетарным гипервизором? Или вы опять по мере сил пиарите любимый XEN? Дык я не против пользуйте XEN или что вам больше нравится. Не нужно только в такую ажитацию впадать при виде других продуктов. :)
Кстати было бы любопытно послущать про мега фенечки виртуализации, которые не снились Microsoft.
Выбор гипервизора может быть продиктован еще и вопросами привычности тех. или иных технологий. Вопросами интеграции с уже существующей инфраструктурой. Долей рынка у того или иного вендора.
VMWare — ровно такая же проприентарщина, как и MS.
Я не пиарю конкретно XEN, я пиарю опенсорсную виртуализацию. RH вообще в сторону KVM уползает, и он уже вполне product-ready.
А из фич… Ну, поехали: pure virtual networks между несколькими хостами пула, сохраняющиеся при миграции.
IntelliCache, позволяющий в разы снизить количество иопсов на shared storage за счёт кеширования на локальных дисках хостов (в рамках XCP локальные диски не используются для хранения данных пользователей).
Фильтрация трафика на втором-третьем уровне, шейпинг трафика виртуальных машин на уровне виртуального коммутатора.
Построение datapath по коммутаторам с помощью openflow и его контроллера (когда путь конструируется не методами VLAN/коммутатции/маршрутизации/MLPS, а прямым указанием чей трафик через какой порт куда передать, и делает это централизованный кластер контроллера исходя из любых прихотей вышестоящего ПО.
А можно подробнее про pure virtual networks. В чем их суть и что в них такого замечательного?
Передача трафика это дело провайдерf системы коммутации. Вам не кажется что так логичнее? Почему то VMWare не стала изрбретать велосипед а использует коммутаторы Cisco для этих целей.
SP2 для 2008 после которых винды таки наконец-таки узнали про существование \linux\Documentation\memory-hotplug.txt.
О pure virtual networks. Они имеют смысл в условиях гомогенного пула (я не знаю, как там у MS вообще с пулами и миграциями). Если у вас две виртуальные машины хотят общаться приватно, то вы можете либо настроить им реальный datapath с использованием vlan, или огранизовать pure virtual network. В этом случае виртуалки получают защищённую сверхвысокопроизводительную сеть (я мерял, на зеонах там около 30Гбит получается), высокая производительность объясняется ещё полным отсутствием всякого геморроя с CRC, гигантскими размерами payload и TCP offload с фактическим игнорированием TCP заголовков). Получается что-то уровня сокетов, но с IP-адресацией, и возможностью работать с сетью многим машинам одновременно.
Это было давно и у всех.
А теперь вопрос: а если мы машину умигрируем куда-нибудь подальше? Линк порвётся? Ай-ай-ай. Вот тут-то и distrubuted pure virtual network и сгодится.
Относительно цисок… Я смотрел на их железо «под виртуализацию», но это реальная ахинея. Они совсем не учитывают существование IDC в пределах хоста, так что путь VMWare с distributed switch (и его опенсорсной реализацией в лице open vswitch в Xen) куда логичнее и мощнее по концепции (а значит, даёт меньше побочных эффектов и больше фич).
Если же нужно динамически удалять и добавлять память из виртуальных машин то для этого есть механизм Dynamic Memory реализованный в SP1 Windows Server 2008 R2.
Тогда к чему был вопрос? Покрасоваться на публике, ввести в заблуждение читателей и распространять FUD и еще раз попиарить XEN? Вдруг кто то еще не знает про Dynamic Memory?
Впрочем я могу списать на то что с вами приключилась банальная амнезия. :)
Функционал pure virtual networks реализуется с помощью Live migration+vlan. Если хочется защиты трафика дополнительно к vlan или вместо него можно использовать IPsec.
Если нужен большой payload и аппаратное ускорение используем TCP offload (Chimney) + Jumbo frames.
Если посмотреть в поиск то оказывается про Live migration вы тоже в курсе
Насколько я понимаю скорости в 30 ГБит/c вы достигли при передаче трафика между виртуальными машинами на одном физическом узле?
> Получается что-то уровня сокетов, но с IP-адресацией, и возможностью работать с сетью многим машинам одновременно.
Вы изобрели свой TCP/IP с го и гейшами? Кто еще поддерживает эту технологию? У нее есть название?
> Относительно цисок… Я смотрел на их железо «под виртуализацию», но это реальная ахинея. Они совсем не учитывают существование IDC в пределах хоста, так что путь VMWare
Вот сюрприз то. Cisco и не в курсе что делает плохие коммутаторы. А как Vmware то огорчится этому ведь они до сих пор используют Cisco в своих рекомендованых конфигурациях.
Уточню. У VMware виртуальный коммутатор Cisco — это опция за дополнительные деньги. Есть и свои виртуальные коммутаторы, если не требуется расширенного функционала от Cisco.
К сожалению дело в том, что один раз купив и внедрив проприетарное решение очень сложно вырваться из порочного круга. Ни открытая система виртуализации никогда не будет тратить силы на поддержку проприетарной платформы не только из принципиальных соображений, но и по причине страха перед упомянутыми троллями, которые могут набежать и сказать мол де вы скопировали алгоритмы из нашей крутой системы.
Если бы в мире все было идеально то патентного тролинга и прочих неприглядный вещей не было бы. Но к сожалению это не так.
Раньше тяжелые задачи решались преимущественно с помощью закрытых решений именно поэтому появился HP, SUN, Oracle и прочие.
Сейчас выбор стал разнообразнее. Но закрытые системы в которые уже вложены деньги как то надо поддерживать и революцию врядли одобрят, поэтому ИМХО та система что поддерживает виртуализацию и открытого и закрытого будет в более выгодной позиции.
Заметьте как часто в ваших комментариях встречаются слова «деньги» и «выгода». Я как обычный человек редко получаю какие-либо положительные результаты, когда эти понятия стоят на первом месте у производителя чего угодно. И это относится не только к IT.
Я работаю в коммерческой организации обслуживающей другие организации и потребителей ИТ продуктов.
Когда приходишь к ИТ менеджеру в любой организации его первый вопрос будет о стоимости владения, возврате инвестиций, стоимости поддержки a это всё деньги. Если для него деньги на первом месте значит и я стараюсь говорить с точки зрения экономических показателей.
Поэтому считаю что хороший ИТ менеджер должен в первую очередь заботиться о выгоде своей организации.
В идеале да. Но я очень сомневаюсь что ИТ менеджер в ответе за всю организацию и ее отношение к людям. Максимум он может влиять на отношение к своим непосредственным подчиненным.
Задача ИТ менеджера — чтобы ИТ сервисы беспрерывно работали и были экономически оправданы.
По вопросам отношения к людям и обшей политики компании это вам наверно к совету директоров надо обращаться.
Вот только не надо валить всё на совет директоров. Есть отличное выражения на эту тему: армия держится на сержантах. Что означает средний уровень иерархии определяет суммарный результат.
Ежели вам очень хочется пообщаться на темы корпоративных идеологий и отношений к людям я не прочь продолжить это в привате или какой либо специальной теме. Но мне кажется что этот топик ближе к технологиям виртуализации и судя по отсутствию плюсов тема людей тут мало кому интересна.
>Итак, вопрос: нахрена вместо opensource решений, которые не имеют vendor lock'а лезть в жаркие объятия проприентарщины?
Есть одна маленькая компания под названием Southwest Airlines (http://en.wikipedia.org/wiki/Southwest_Airlines). Первый дискаунтер и самый коммерчески успешный.
В том числе по причине не то что Vendor Lock-in, а даже model lock-in. Они используют исключительно Boeing 737 (более 500 самолетов), и в силу этого экономят очень сильно. Не требуется содержать огромный склад зап частей для целой кучи разных моделей, не требуется даже менять высоту корридора на гейте. Не требуется постоянно учить сервисников как обслуживать разные самолеты, а можно потратить время на изучение и настройку своих 737 в полный рост. И при этом у них еще и скидки от Боинга за счет огромных объемов поставок.
Даже в сфере ПО использование моновендорной системы выходит дешевле зоопарка.
Если стоимость простоя и прервывания бизнеса велика думаю без коммерческой поддержки не обойтись. А это значит что надо обращаться к вендору не важно проприетарный он или опенсорсный.
И как вы тогда без конкретного производителя обходиться собираетесь?
Утверждение о том, что моновендорное решение выгоднее, чем подбор ПО под задачу… Ну представьте себе сравнение виндов на десктопе и полного серверного ПО от МС с вариантом серверного по на линуксе. Очевидная же разница будет.
И речь идёт не о том, что нужно делать мультивендорное решение, а о том, что поддерживая старую и протухшую проприентарщину не нужно в неё вплетать новую и свежую проприентарщину. Разные вендоры — уже предопределено протуханием SCO, значит, что-то должно быть? Почему тогда MS, а не опенсорс?
Задач в организации много и для каждого ПО отдельный вендор? Под каждое ПО обучать персонал заново? Отдельный тех. саппорт для каждого ПО?
Часто бывает проще и дешевле взять в все в комплекте у одного вендора или двух. Лешче интегрировать и обслуживать.
Вы заговорили о Vendor Lock-In, что нельзя зависеть от вендора.
Точно так же Southwest Airlines могла выбрать вариант, при котором есть равное количество самолетов от Boeing и Airbus, и про запас еще несколько производителей. На всякий случай, если Boeing вдруг начнет себя вести некрасиво.
Southwest Airlines в позиции Vendor Lock-In с 1971 года, когда состоялся первый коммерческий полет. И прекрасно себя чувствуют.
Вы сейчас предлагаете купить автомобиль, но ни в коем случае не пользоваться двигателем, который поставляется с ним же. Ведь тогда будет страшный и ужасный vendor lock-in. Вместо этого вы предлагаете в Scania поставить опенсурс двигатель, разработанный с миру по нитке случайными людьми, произведенный в Китае и без какой-либо поддержки. Зачем? Мы же сами с усами, разберемся. У нас даже все исходники есть, сами будем кованые поршни делать и коленвал точить.
Vendor Lock-in — это не так ужасно, как Вы и большинство фанатов GNU / Free Software пытаются показать. Более того, если правильно пользоваться, то именно за счет этого можно очень экономить.
Из ружья можно убить утку, а можно выстрелить себе в ногу. Но наверное в этом случае будет виновато не ружье?
С OS/2 происходило то же самое. Очень многие перешли на использование пополама в VM, в дальнейшем, вероятно с плавным переползанием на eComStation или переписыванием софта (конкретные случаи — несущественны).
Виртуализация SCO OpenServer 5.0.7V под Hyper-V