Pull to refresh

Comments 75

Мне одному кажется, что статья ниачём?
Да не парьтесь вы, найдутся, видимо, на хабре и те, кому такие статьи будут очень полезны. Человек начал осваивать Hyper-V, хочет поделиться своей радостью с миром. Пусть делится, жалко, что ли?
Человек показывает другим как правильно готовить Hyper-V.
Так сказать облегчает им путь освоения технологии. :)

Впрочем, когда я писал про инфраструктуру на Unix/Linux тоже были те кому все понятно и известно. Одно мне не ясно, что их так тянет в мои топики? Самоутвердится хочется?
Хочется выразить недоумение в адрес копипасты с вашего блога на технете. Это запрещено правилами Хабра. Также хочется выразить сомнение в необходимости таких вот «обзорных» топиков. Выглядят они как инструкции для обезьянки с картинками. Соли маловато и перца не хватает.
Самоутвердиться, очевидно, хочется вам, но как-то способ выбран странный.
Считаете этот материали недостаточно глубоким для своего взыскательного вкуса. Отлично я не против продолжайте считать так дальше. Только определитесь уже как нибудь со своим мнением окончательно а то вас трудно понять:

> Да не парьтесь вы, найдутся, видимо, на хабре и те, кому такие статьи будут очень полезны

> Также хочется выразить сомнение в необходимости таких вот «обзорных» топиков.

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

habrahabr.ru/blogs/android/110609/
habrahabr.ru/blogs/android/110579/

Эти топики для кого? Тоже для «обезъянок» только с Android?

Тем не менее я не считаю себя вправе приходить в ваши топики и писать комменты в стиле «что за ерунда». Раз вас читают значит кому то это нужно.

Мое мнение что профессионалами не рождаются поэтому те кого вы сегодня назвали «обезъянками» через некоторое время станут специалистами и понятные подробные иструкции весьма облегчат им жизнь.
Вы еще и сарказм не различаете. Ну прямо Шелдон.
Указанные вами топики — новостные. Ничего необычного. Я не пытаюсь самореализоваться на хабре, я вообще его воспринимаю скорее как аггрегатор ИТ-новостей и околоайтишной информации. Иногда проскакивают и годные авторские топики.
Приходите в мои топики и пишете что угодно. Для этого и пишутся публичные топики.
«Профессионалы», обучающиеся на комиксах никогда не ими станут. Это мое ИМХО. Пока своими собственными руками и мозгами не расковыряешь до дна интересующую тебя технологию — будешь эникеем и обезьянкой.
Чтобы начать что то ковырять руками и понять как оно работает обычно люди начинают с чтения учебника. Часто в нем бывают картинки и инструкции вероятно это как раз для «обезъянок» написано.

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

Данный топик лишь короткая инструкция для начала изучения и proof of concept для тех кто просто интересуется гипотетической возможностью миграции SCO OpenServer под Hyper-V.
Да, эти три человека вам благодарны.
Судя по +21 в теме людей которым это пригодилось несколько больше чем 3. :)
А расковыривать я так понимаю вы начинаете сразу, как только видите ПО. Откладываете все мануалы и в слепую в бой, ага.
Мануалы не имеют ничего общего с творчеством ТС. Кстати, коммент на который вы отвечаете — детектор своего рода. Палитесь, товарищ.
>Кстати, коммент на который вы отвечаете — детектор своего рода. Палитесь, товарищ.
У меня такое ощущение, что вы ведете внутренний диалог сам с собой. Пытаетесь доказать, что вот мы тут все не правы. Может вы не в курсе, что это глупо? Потому как, когда мне в свое время требовалась помощь что-то понять и разобраться, то вопросы на форумах тематических и т.п. пересылались в гугл, вот такими же зазнайками, как вы.
Нет, я не в курсе. Расскажите мне.
Я ничего никому не пытаюсь доказывать, вам померещилось. Вас в детстве били зазнайки, что ли?
:) больше даже нечего вам ответить
Куда не посмотришь везде творчество, превыше всего. Вы не разработчик часом? :)

А сделать стабильно работающую и поддерживаемую вендором конфигурацию инфраструктуры, которая будет обслуживать миллионы абонентов это конечно не творчество, потому как по мануалам, гайдам и прочим лучшим практикам сделано. :)
Креативность превыше всего. Фурсенко вон высшую математику не изучал — и ничего, не дурее других.
У Фурсенко к сожалению сфера деятельности другая. То что ему точные науки не нужны не означает что любой инженер сможет всю жизнь выезжать не креативности.

Боюсь представить что будет если инженеры в машиностроении начнут раз за разом подходить к тех. процессу изготовления продукции креативненько. :)
Нет, не разработчик. Не дано, увы, я сраное лохе в этих вопросах.

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

Если вы не знаете, что такое ТС, то это простительно.
Крупные инфраструктуры обычно строятся на основе гайдов, мануалов и best practice от вендора.

Вы за творческую интерпретацию этих документов?

Кто платить за не поддерживаемое решение будет ежели оно упадет?

Неужели? Вы открыли мне глаза.
Оке, расшифрую. ТС — Топик Стартер. Теперь перечитайте свои комменты, начиная отсюда.
Я почему-то подумал, что Вы имели в виду Technical Consultant
на самом деле из топика я не узнал, как правильно готовить Hyper-V, но узнал, что sco жив и будет жить еще долго, и его вполне можно виртуализировать с помощью Hyper-V(ксати, при помощи VMware тоже можно как пишут здесь)
Думаю каких либо проблем с виртуализацией SCO под VMWare так же не должно быть.

А топики про разные трюки во время приготовления Hyper-V еще впереди. :)
Кто ж вам мешает написать свою статью «О чем надо». :)

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

Как вы думаете сколько ИТ специалистов будут возиться с детальным исследованием, если им поставят задачу виртуализировать SCO?
В этой статье я вижу какое «детальное» исследование проведено вами на основе работающей инсталляции, запуска ifconfig и гуя для менеджера пакетов :)
Каждый верит в то во что хочет верить. Видимо до нагрузочного тестирования вы не дочитали.

Кстати, если не сложно продемонстрируйте пожалуйста ваши «детальные» исследования по любой угодной теме. :)
Ммммм… Предложение про прокачку пары HD-фильмов через самбу я прочитал.
Что-то я не вижу здесь тестов виртуального процессора, если уж используется банком то процессинговые сервисы как раз процессор нагружать и будут.
Не вижу тестов стабильности NFS, который все нормальные люди используют, чтобы шарить дисковое пространство между серверами.
Не вижу тестов комбинированного ПО, которое задействует сетевую и дисковую подсистемы.
Не вижу тестов того, как сетевая подсистема ведёт себя, когда на сервер долбится 100 конкурентных подключений.
> Не вижу тестов комбинированного ПО, которое задействует сетевую и дисковую подсистемы.

Как думаете куда файлы закачанные на Samba попадают? Неужели через сетевую подсистему на жесткий диск?

> Не вижу тестов того, как сетевая подсистема ведёт себя, когда на сервер долбится 100 конкурентных подключений.

Файлы я копировал в несколько потоков скриптами. Видимо надо было написать про это.
UFO just landed and posted this here
Вы ещё не поняли? Это статья-кармогенератор для подразделения евангелистов Microsoft на Хабре.
Довожу до вашего сведения что евангелистам Microsoft не обязательно иметь положительный баланс кармы чтобы писать на хабре.

Для этого есть корпоративный блог.
Не статьями едиными. Ведь есть куча других применений. Например проталкивать нужные и низводить ненужные публикации, приглашать других евангелистов Microsoft на Хабр…
Честно говоря низводить чьи бы то ни было публикации не вижу смысла. На каждый товар будет купец. Слишком по детски бороться неизвестно с кем в интернете.

Если вы не в курсе у Microsoft здесь платный блог как и у других коммерческих компаний. Это означает что мы можем практически не переживать ни о своей ни о чужой карме.

Я пишу в блог Виртуализация потому что освещаемая тема более узка. Хотя спокойно мог бы постить без оглядки на карму в официальный блог сколько влезет.
То что вам не интересна виртуализация под Hyper-V не означает что она не интересна другим читателям.

Судя по оценкам статьи пользуются успехом и нашли свою аудиторию.
А чем отличается виртуализация под Hyper-V от любой другой виртуализации? Мордой к запускалке и конфигурялке машин разве что.
Поддержкой гостевых ОС, драйверами. Особенностями кластеризации. Тем как реализовывать резервное копирование виртуальных сред. Как делать их массовое развертывание. Как проводить мониторинг.

Может именно про это и стоит написать? Как кластеризовать Hyper-V, как делать массовое развертывание, как проводить мониторинг?

Лично я вот про это не знаю и мне было бы интересно почитать. и целевая аудитория я думаю шире чем администраторы SCO.

ИМХО.
Мануалов вы уже прочитали и не нашли там ответа?
Почитал вашу статью — понравилось, хоть и не моя областья деятельности.
Я одного не могу понять. Почему ради поддержки Старых Уродливых Систем нужно ставить Новые Уродливые Системы?

Неужели опыт SCO никого не научил? Когда-то они были Большими и Важными и все склонялись в позе почтительного рабства перед их Vendor Lock'ами.

Теперь они — пустое место и полигон для патентных троллей.

Так зачем же от старого вендор лока добровольно подстилаться под новый вендор лок? Да, сечас они Большие и Важные, но всё меняется, не так ли?

Итак, вопрос: нахрена вместо opensource решений, которые не имеют vendor lock'а лезть в жаркие объятия проприентарщины?

Сбербанки плакали, кололись, но продолжали юзать проприентарный софт?
UFO just landed and posted this here
Немного не так. Плакал и кололся сбербанк, а вот кактус продолжал жрать их ИТ-отдел.
Я как раз ждал когда в топик примчатся ненавистники SCO. :)

Видно для вас термин стоимость миграции ничего не говорит?

Кто даст денег на революцию во имя идеи свободного ПО в рамках одной компании с переписыванием всего того ПО что работает сейчас на SCO?

Сколько будет длиться проект миграции? Сколько будет стоить переобучение персонала?

Риски от прерывания бизнес процесса вы считали? Готовы риснуть работой крупного банка?

Почему то немецкие банки не спешат переходить с OS/2 на что то новое, а используюют ее до сих пор под эмуляцией. Видимо их в первую очередь интересует экономия бюджета, а не борьба за светлые идеи свободы во всем мире.

Я тоже не в восторге от поведения SCO за последние годы, но экономические вопросы выгоды и затрат на ИТ обслуживание предпочитаю держать отдельно от идеологии. Посему смотрю на вопрос сугубо прагматично.
Стоп, вы не поняли.

Я говорю не про «переписать всё SCO под линукс». Упаси боже.

Я говорю «не надо использовать проприентарные гипервизоры».

Зачем садиться на иглу майкрософта, когда есть опенсорсные гипервизоры, причём со всеми фенечками, какие есть у VMWare, и которые MS не снились?

Неужели опыта SCO не достаточно, чтобы понять, что даже самый Большой и Важный в конце-концов оказывается в положении «труп с кучей вкусных патентов»?
А VMWare перестал быть проприетарным гипервизором? Или вы опять по мере сил пиарите любимый XEN? Дык я не против пользуйте XEN или что вам больше нравится. Не нужно только в такую ажитацию впадать при виде других продуктов. :)

Кстати было бы любопытно послущать про мега фенечки виртуализации, которые не снились Microsoft.

Выбор гипервизора может быть продиктован еще и вопросами привычности тех. или иных технологий. Вопросами интеграции с уже существующей инфраструктурой. Долей рынка у того или иного вендора.
VMWare — ровно такая же проприентарщина, как и MS.

Я не пиарю конкретно XEN, я пиарю опенсорсную виртуализацию. RH вообще в сторону KVM уползает, и он уже вполне product-ready.

А из фич… Ну, поехали: pure virtual networks между несколькими хостами пула, сохраняющиеся при миграции.

IntelliCache, позволяющий в разы снизить количество иопсов на shared storage за счёт кеширования на локальных дисках хостов (в рамках XCP локальные диски не используются для хранения данных пользователей).

Фильтрация трафика на втором-третьем уровне, шейпинг трафика виртуальных машин на уровне виртуального коммутатора.

Построение datapath по коммутаторам с помощью openflow и его контроллера (когда путь конструируется не методами VLAN/коммутатции/маршрутизации/MLPS, а прямым указанием чей трафик через какой порт куда передать, и делает это централизованный кластер контроллера исходя из любых прихотей вышестоящего ПО.

Непрерывная репликация VM, позволяющая виртуалке без даунтайма пережить падение виртуализирующего хоста.

Memory hot-unplug, который MS даже в глаза не видела (hotplug только-только реализовали в SP2).

Поддержка NUMA-хостов (Что там MS про линукс на суперкомпьютерах думает?)

Регулируемая эмуляция TSC, позволяющая получить и стабильность и производительность одновременно.

Если зен и vmware борятся нос-в-нос, то сравнивать Xen и hyper-v просто нелепо. hyper-v сейчас только-только реализует то, что было в xen 2.0.
А можно подробнее про pure virtual networks. В чем их суть и что в них такого замечательного?

Передача трафика это дело провайдерf системы коммутации. Вам не кажется что так логичнее? Почему то VMWare не стала изрбретать велосипед а использует коммутаторы Cisco для этих целей.

Про какой SP2 вы говорите? Для Hyper-V?
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) куда логичнее и мощнее по концепции (а значит, даёт меньше побочных эффектов и больше фич).
Hotplug memory реализован уже давно в Windows
www.microsoft.com/whdc/system/pnppwr/hotadd/hotaddmem.mspx

Если же нужно динамически удалять и добавлять память из виртуальных машин то для этого есть механизм Dynamic Memory реализованный в SP1 Windows Server 2008 R2.

Почитать о Dynamic Memory можно вот тут
habrahabr.ru/search/?q=Dynamic+memory

Судя по тому что всех темах про Dynamic Memory вы отметились комментами я считаю что вы о ее существовании знаете.

habrahabr.ru/blogs/virtualization/93241/

Тогда к чему был вопрос? Покрасоваться на публике, ввести в заблуждение читателей и распространять FUD и еще раз попиарить XEN? Вдруг кто то еще не знает про Dynamic Memory?

Впрочем я могу списать на то что с вами приключилась банальная амнезия. :)

Функционал pure virtual networks реализуется с помощью Live migration+vlan. Если хочется защиты трафика дополнительно к vlan или вместо него можно использовать IPsec.

Если нужен большой payload и аппаратное ускорение используем TCP offload (Chimney) + Jumbo frames.

Если посмотреть в поиск то оказывается про Live migration вы тоже в курсе

habrahabr.ru/company/croc/blog/102540/

Это как бы намекает на развитие амнезии.

Насколько я понимаю скорости в 30 ГБит/c вы достигли при передаче трафика между виртуальными машинами на одном физическом узле?

> Получается что-то уровня сокетов, но с IP-адресацией, и возможностью работать с сетью многим машинам одновременно.

Вы изобрели свой TCP/IP с го и гейшами? Кто еще поддерживает эту технологию? У нее есть название?

> Относительно цисок… Я смотрел на их железо «под виртуализацию», но это реальная ахинея. Они совсем не учитывают существование IDC в пределах хоста, так что путь VMWare
Вот сюрприз то. Cisco и не в курсе что делает плохие коммутаторы. А как Vmware то огорчится этому ведь они до сих пор используют Cisco в своих рекомендованых конфигурациях.

www.vmware.com/products/cisco-nexus-1000V/

Один вы отлично знаете как делать коммутаторы. :)
Уточню. У VMware виртуальный коммутатор Cisco — это опция за дополнительные деньги. Есть и свои виртуальные коммутаторы, если не требуется расширенного функционала от Cisco.
Что сейчас используется под VMWare для реализации свича+мирроринга? Использовал Solera Virtual TAP, но сейчас проект вымер.
Встроенного механизма мирроринга трафика на физические порты у VMware нет. Мирроринг на виртуальные порты — стандартный функционал.
Таки не понял, это все про KVM или Xen написано? Я про фичи.
Агитация была за опенсорнсые гипервизоры, а уж фичи, извините, я зеновские называл, ибо его я много лучше знаю.
К сожалению дело в том, что один раз купив и внедрив проприетарное решение очень сложно вырваться из порочного круга. Ни открытая система виртуализации никогда не будет тратить силы на поддержку проприетарной платформы не только из принципиальных соображений, но и по причине страха перед упомянутыми троллями, которые могут набежать и сказать мол де вы скопировали алгоритмы из нашей крутой системы.
Если бы в мире все было идеально то патентного тролинга и прочих неприглядный вещей не было бы. Но к сожалению это не так.

Раньше тяжелые задачи решались преимущественно с помощью закрытых решений именно поэтому появился 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 в полный рост. И при этом у них еще и скидки от Боинга за счет огромных объемов поставок.

Расскажите им как вреден vendor lock-in.
Ну, если бы они использовали опенсорнсые самолё… oh, wait.

Другими словами, в условиях _вещей_ без конкретного производителя не обойтись. Но мы же про ПО говорим, нет?
Даже в сфере ПО использование моновендорной системы выходит дешевле зоопарка.

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

И как вы тогда без конкретного производителя обходиться собираетесь?

Утверждение о том, что моновендорное решение выгоднее, чем подбор ПО под задачу… Ну представьте себе сравнение виндов на десктопе и полного серверного ПО от МС с вариантом серверного по на линуксе. Очевидная же разница будет.

И речь идёт не о том, что нужно делать мультивендорное решение, а о том, что поддерживая старую и протухшую проприентарщину не нужно в неё вплетать новую и свежую проприентарщину. Разные вендоры — уже предопределено протуханием 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 пытаются показать. Более того, если правильно пользоваться, то именно за счет этого можно очень экономить.
Из ружья можно убить утку, а можно выстрелить себе в ногу. Но наверное в этом случае будет виновато не ружье?
UFO just landed and posted this here
С OS/2 происходило то же самое. Очень многие перешли на использование пополама в VM, в дальнейшем, вероятно с плавным переползанием на eComStation или переписыванием софта (конкретные случаи — несущественны).
Sign up to leave a comment.

Articles