Vmware

В Москве семь часов вечера. Рабочий день подошел к концу. Коллеги прощаются, закрывают лэптопы и выходят из Zoomа. Город потихоньку засыпает, просыпаются айтишники. 19:00 по Москве это 08:00 в Сан-Франциско. Моя подруга из VMware Маша Шалдыбина делает утренний кофе, логинится и впрочем, обо всем по порядку.

Привет, Хабр. Меня зовут Катя Юдина, я руководитель контент-маркетинга облачного бизнеса МТС. Буквально на днях я взяла небольшое интервью у своей давней подруги, которая сейчас работает в центральном офисе хоум-офисе компании VMware. Под катом вас ждет интересный рассказ о карьере ИТ-специалиста в крупной международной компании. Поговорим о том, как происходит трудоустройство на западе, как устроена работа в VMware и почему мировой карантин почти никак не затронул отдел разработки.

Кстати, у нас отличная новость! Если у вас нет времени на чтение, можно прослушать подкаст-версию статьи по этой ссылке.

Маша, как начался твой путь в ИТ?

Скорее, не как, а когда в раннем детстве. Повлияла семья: оба родителя у меня физики. Так что у нас дома постоянно была разная электроника, даже компьютеры (что на тот момент было большой редкостью). Я достаточно рано освоила Бейсик. Помню, устраивала себе развлечение: писала программы, которые рисовали разные картинки на экране. Уже в школе заинтересовалась онлайн-играми, они как раз тогда только-только пошли. Когда я училась в 10 классе, была очень популярна Ragnark Online. Игрушка меня заинтересовала, но сам геймплей показался неторопливым. Нужно было постоянно фармить и ждать. Так что я развернула свою собственную версию и начала копаться в ее коде, чтобы настроить игру под свои хотелки.

Мы тогда жили в Ташкенте, и ВУЗ я выбрала достаточно быстро. Моя альма-матер Ташкентский Университет Информационных Технологий. Собственно, направление Информационные технологии тогда только открылось. Мы много экспериментировали, делали что-то новое. Преподаватели тоже не отставали, учились вместе с нами. Там же я защитила диссертационную работу, самописную CMS для веб-сайтов.

Ты помнишь свое первое место работы?

Еще бы! Курсе на четвертом моя подруга, Юлия Яковлева, схантила меня поработать в местном интернет-провайдере. К своему удивлению, собеседование я прошла быстро и без проблем, чего нельзя сказать о первых месяцах моей работы. Вышло так, что разработчик, писавший биллинговую систему для компании, через две недели уволился. Я осталась один на один с этой системой. Пришлось очень много выучить в кратчайшие сроки на собственных ошибках, с помощью коллег-администраторов

Еще в ВУЗе я познакомилась с будущим мужем, Олегом. Дальше мы двигались вместе. Стало понятно: если мы хотим добиться большего, понадобится переезжать. Из Ташкента мы отправились в Санкт-Петербург. Там мы продолжили карьеру веб-разработчиков: я в Daxx, а Олег в Murano.

Тем не менее, мы все время находились в поисках лучшего. Через какое-то время муж прошел интервью в Microsoft, и его пригласили на работу в парижский офис. Но судьба распорядилась иначе. У компании, в которой он тогда работал, было много клиентов из США. Когда одному из них стало известно, что муж увольняется, он предложил ему дальше работать напрямую. Почему бы и нет?

Дальше началась маета с визами. После первого интервью в посольстве США на J-визу мы получили отказ. Пришлось штурмовать Америку заново. Наученные горьким опытом и добрым послом, мы подготовили новый пакет документов и подали на визу H1B. Шел 2008-й, год финансового кризиса, даже лотерея тогда не проводилась из-за недобора запросов (если в первый день подачи документов на визу, первого апреля, не набирается 65000 запросов, лотерею не проводят).

Для визы пришлось подготовить действительно много документов с базовым списком можно ознакомиться на сайте посольства. Вдобавок мужу пришлось в деталях расписать, ради какого проекта он едет в Штаты: архитектура веб-сайта, предстоящие задачи и все в таком духе. Все это проверялось в посольстве, так что схитрить вряд ли бы вышло.

Эти же документы мы взяли с собой в Америку. Таможенник на границе проявил компетентность и долго расспрашивал нас про этот сайт. Нам показалось даже, что он украдкой зашел на него во время беседы. Когда очередь дошла до меня, я сказала, что работать не планирую виза не позволяет. Таможенника этот ответ устроил, и мы, наконец, услышали заветное: Welcome to the United States.

Ты сразу пошла на работу в VMware?

Нет (смеется), еще целый год после переезда я не могла устроиться на официальную работу. Нам очень помог работодатель Олега: встретил нас, поселил в своем доме, пока мы не нашли собственное жилье. Помог купить подержанный автомобиль без машины здесь никак.

Самый главный документ США, SSN (номер социального страхования, который присваивается всем гражданам и резидентам США), мы оформили быстро и без проблем. Всю информацию в доступной форме можно найти на сайтах агентств.

Разумеется, сложа руки я не сидела. Постоянно решала задачи на всяких Topcoderах и CodeSprintах, готовилась к интервью. Есть такая хорошая книга Cracking the Coding Interview. В ней описано, как проходить собеседования в крупных ИТ-компаниях, таких как Google или Facebook. Много хороших задач с решениями, рекомендую. Еще я прошла сертификацию на знание языков программирования, создала приложение для iPhone то есть, всеми силами старалась сформировать хорошую базу для устройства на работу.

Cracking the Coding Interview

Когда через год я получила разрешение на работу, началась фаза активных поисков компании мечты. У меня были друзья в Facebook с их помощью удалось получить приглашение на интервью. Здесь важно понимать: в Америке как нигде сильно понятие leverage потенциальный работодатель может заинтересоваться тобой, если ты упомянешь о собеседовании в другой компании того же ранга. Так что интервью в Facebook мне помогло получить приглашение от VMware. Они устроили все очень быстро, предложили даже пропустить телефонный этап и сразу пригласили on-site в офис. Дальше все достаточно стандартно: мне дали несколько задач, после решения я лично поговорила с руководителями и получила оффер. Собственно, так я и попала в VMware.

Расскажи подробнее об интервью. Что требуется, какой бэкграунд нужен кандидатам? Как проходит собеседование в деталях?

Универсально рассказать не получится, тут все зависит от должности, на которую ты подаешь резюме, и от людей, которые будут проводить собеседование. В целом за день может быть четыре-пять разных бесед. Из них три, например, могут вести программисты кандидату предложат решить задачки на программирование (перевернуть связанный список, решить задачу с установкой зависящих друг от друга приложений и т.п.). Чаще всего код пишется на белой доске маркером.

Может быть беседа с HR спрашивают про карьеру, цели, почему именно к нам?. Еще одна интересная разновидность интервью на дизайн. Писать код уже не придется вам зададут некий общий вопрос из серии как бы вы построили подобное приложение? и попросят обосновать свой выбор.

А что после собеседования? Сразу в поле или есть какая-то адаптация?

На самом деле, ввод новых сотрудников в эксплуатацию у нас поставлен очень грамотно, что называется на потоке. Первые пару недель занимают групповые тренинги и лекции. Тебя знакомят с компанией, ее целями, продуктами и историей. Затем прикрепляют к конкретной команде разработчиков и дают менеджера. Задания выдают попроще. В VMware для учета багов и фич используется Pivotal Tracker весьма удобный инструмент, а для команд менее 5 человек он доступен бесплатно. Обычно раз в неделю обсуждается, кто из сотрудников над какой задачей будет работать. Вливание в работу очень мягкое и спокойное. Все хорошо документировано, так что типовых проблем надо срочно что-то делать, но непонятно как не возникает.

Pivotal Tracker

Когда я присоединилась к VMware, мне поручили работу в проекте Cloud Foundry. На тот момент он существовал всего год. В двух словах, Cloud Foundry это система, которая позволяет разработчикам запускать свои приложения в облаке. Лично я работала над компонентами, отвечающими за корректную работу приложений, написанных на Node.js, он тогда как раз был на пике популярности.

Интересный момент как известно, основная деятельность VMware долгие годы была сосредоточена на решении достаточно низкоуровневых задач, близко к железу. А Cloud Foundry это уже software-level, он выбивался из концепции. Поэтому все высокоуровневые проекты решено было объединить в компанию Pivotal. То есть фактически это родная сестра VMware, обе находились в собственности Dell.

Таким образом, я перешла из VMware в Pivotal. Кто-то из моих коллег был против перехода, они остались в VMware, ушли на другие проекты. Дело было в экстремальном agile-подходе к написанию кода, принятом в Pivotal. Парное программирование, SCRUM-собрания. Мне это показалось интересной возможностью научиться чему-то новому, да и с людьми мне общаться легко. Почему бы и нет?

Так началась моя карьера в Pivotal. Спустя семь лет после начала моей работы компанию купила VMware, и я вернулась туда, откуда начинала (смеется).

На самом деле, все оказалось не так страшно. Сессии парного программирования устраиваются ежедневно с 9 утра до 6 часов вечера. Все очень хорошо организовано: на утреннем стендапе мы определяемся с пулом задач и выбираем себе пару. Садимся за один компьютер, работаем над одним и тем же кодом, но при этом у каждого свои монитор, клавиатура и мышь. Практика парного программирования обычно подразумевает, что один из нас драйвер, ведущий, а второй ведомый. Роли распределяются так: драйвер печатает код, фолловер проверяет и смотрит наперед, какие ошибки могут возникнуть в его работе. Идет постоянное обсуждение, как можно улучшить то или иное решение. Это очень помогает решать сложные задачи как известно, одна голова хорошо, а две лучше. Для продуктивности роли внутри пары меняются, обычно в середине дня. Кстати, у нас есть инстаграм, там можно посмотреть, как выглядят наши рабочие будни и праздники.

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

Минусы тоже есть. За неделю накапливается эмоциональная усталость от постоянного общения с другим человеком. Приходится говорить, о чем ты думаешь. Описывать ход своих мыслей. Чтобы сотрудники не выгорали, по пятницам у нас этакий день разработчика никакого парного программирования, все занимаются тем, что сами считают нужным для развития.

А как вы уходили на карантин? Были сложности с построением коммуникации с удаленным партнером по программированию?

Мы начали переход на удаленный режим работы еще до карантина. У нас было много офисов в Нью-Йорке, Лондоне, Мюнхене. Иногда члены одной команды могли жить в разных городах. Да мы и ранее занимались парным программированием удаленно. Например, в моей команде были ребята из Нью-Йорка. Утром мы все встречались в Zoom, обсуждали дела и разделялись на пары. Собственно, на карантине все происходит точно так же. Ведущий включает демонстрацию экрана, ведомый может делать аннотации и по необходимости перехватывает управление. С кодом работаем в основном в Visual Studio Code. При необходимости разворачиваем виртуальную машину и работаем на ней. В этом сценарии для совместной работы в терминале используем Tmux, а код пишем в Vim. Мы привыкли к такому формату, так что карантин не стал для нас шоком.

У моего мужа, например, сложилась обратная ситуация. Он работает в Google, а там любят, чтобы сотрудники приходили на работу. Удаленка им претит. Офисы для них второй дом: и накормят, и стиральная машина имеется, и поспать можно. Хоть живи, главное из дома не работай. Конечно, им перестроиться было на порядок сложнее.

Вообще, если не говорить о причинах карантина, я вижу в нем много плюсов. Не нужно тратить время на дорогу. В любое время я могу взять перерыв и провести время с дочерью. Благодаря парному программированию после шести вечера ты полностью свободен, никаких овертаймов, связь между сотрудниками осуществляется асинхронно. Никто никого не дергает. Я рада, что в свободное время я могу забыть о работе и быть со своей семьей. Моему сыну три, дочке нет еще и года, справляться с ней помогают родители они всегда рядом и с радостью приходят на помощь.

В двух словах: над какими продуктами ты работала/работаешь?

Над Tanzu Application Service. Я участвовала практически во всех командах разработки: различные бэкенд-подсистемы, фронтенд, интерфейс командной строки, непрерывная интеграция и релиз. Примерно раз в год в проекте происходит ротация, и команды перетасовываются. Это не только предотвращает выгорание, так как не приходится годами долбить одно и то же, но и не порождает новых проблем, что тоже важно. Наоборот, свежий взгляд на код помогает делать его лучше и чище.

Маша, спасибо! Надеюсь, следующий раз получится рассказать об одном дне из жизни разработчика Google :)

***

По традиции, ждем ваших комментариев. Поделитесь своим опытом, расскажите, понравился ли вам такой формат статьи, что стоило бы добавить или изменить. До встречи, друзья!

Не так давно мы публиковали интервью Один день из жизни разработчика VMware рассказ о карьере ИТ-специалиста в крупной международной компании.

А сейчас у нас возникла идея поискать в своем отечестве, и мы обратили внимание на российский офис VMware. Программистов в нем нет, но есть о чем поговорить с инженерами presales. Встречайте Михаил Михеев!

Если вы стояли у истоков использования виртуализации в России, то вы могли знать о нем как о человеке, который:

• вел блог по этой узкой тематике и обучающие курсы;

• участвовал в организации встреч сообщества;

• написал книгу Администрирование VMware vSphere.

Мы решили поговорить с Михаилом по душам и выведать, как он попал в ИТ, почему решил написать собственную книгу и как стал сотрудником VMware, не будучи программистом. Небольшой спойлер: оказалось, под маской уверенного в себе специалиста скрывается обычный человек. Скромный и с превосходным чувством юмора.

Эксперт с форума

Пути, по которым ведет нас жизнь, не всегда поддаются логическому анализу. Порой даже случайности, которым не придаешь особого значения, становятся решающими. Итак, представьте: Казань. Я учусь на последнем курсе университета. Стажируюсь за еду бесценный опыт у местного интегратора. (Большое спасибо им, кстати: я в первые полгода действительно не умел делать ничего полезного, чтобы просить денег.) И вот передо мной поставили задачу разобраться с неподдавшимся с наскока продуктом, Microsoft SMS 2003. Мне удалось найти один админский форум: там я искал информацию и задавал тонны вопросов в основном как раз по этому продукту. В первое время я только спрашивал, затем осмелел и начал понемногу отвечать менее опытным товарищам. Как потом выяснится, потребность делиться знаниями это неотъемлемая часть моего характера.

Мои ответы заметил форумчанин, очень много помогавший мне на начальных этапах. Можно сказать, я рос на его глазах. Совпало, что в то же самое время к нему обратился один из московских учебных центров: мол, есть ли на примете тренер, который может прочитать курс по MS SMS? И он пришел с этим предложением ко мне.

Если мне не изменяет память, потом он рассказывал: Я был впечатлен тем, что на форуме ты не только искал решения для собственных задач, но и в какой-то момент начал помогать другим. Подумал: раз уж ты и разобраться смог, и продолжаешь погружаться прочитать курс тебе вполне по силам.

Сейчас я понимаю, что учебный центр тогда пошел на авантюру, доверив вести серьезный курс неопытному и неизвестному мне. Видимо, вакансия преподавателя совсем горела :)

(Справедливости ради, они сначала со мной очно познакомились, и обеспечили всей возможной поддержкой, так что это не было стереотипным возьмем с заказчиков много денег, а наймем студента.)

Шел 2005 год. Товарищ с форума оставил мне контакты учебного центра. Представьте мое состояние: где я, студент Миша из Казани, а где это достойное заведение! Заметьте: я раньше не только лекции сам не вел, но даже слушателем подобных вендорских курсов мне бывать не доводилось. Я очень ОЧЕНЬ волновался перед звонком.

Но, как говорится, колени дрожат, а руки делают. Я согласился на этот вызов. Мы договорились о личной встрече, я съездил в Москву на собеседование, а дальше как в тумане. Чтобы я получил представление о том, как все это вообще происходит, учебный центр позволил мне принять участие в качестве слушателя на другом курсе. Затем предоставил trainer guide и назначил дату курса уже со мной в роли тренера.

Как потом признался один из сотрудников, во время курса они подкрадывались к двери, скрестив пальцы, и слушали, что происходит в аудитории.

Мне удалось взять себя в руки и во время курса хранить спокойное и доброжелательное выражение лица, несмотря на внутренний котел эмоций. А нервничал я в первые разы, конечно, очень здорово. Желание не ударить в грязь лицом мотивировало раз за разом приходить все более подготовленным. Кучу времени я потратил на штудирование тренинг-гайда, на каждой странице, на каждом слайде выделяя важную и интересную информацию. В буквальном смысле почти на каждой странице толстенной печатной методички у меня были наклеены канцелярские листочки с заметками.

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

Преподавание легло мне на душу. Люди оставляли хорошие отзывы после курсов. Было видно, что они не просто получили удовольствие, но и реальные навыки заработали. По итогам учебный центр предложил мне постоянную работу. Можно сказать, так и началась моя настоящая карьера, и я переехал в Москву.

(Сейчас душевная рана почти затянулась, поэтому расскажу: моя будущая жена смогла переехать лишь спустя целый год. Все это время я жил в Москве один, без нее. Это было отдельным вызовом.)

Со временем я начал читать и другие курсы по продуктам Microsoft немного, буквально две-три штуки. Учебный центр нашел еще одного нишевого вендора, и некоторые курсы по его продуктам тоже достались мне. Приблизительно в то же время (2006 год) на российский рынок вышла и VMware. Мой учебный центр оперативно заключил с ними соглашение, и я стал первым преподавателем по vSphere (тогда продукт носил немного другое название) на территории РФ. Наверное, достаточно долгое время я был вообще единственным. Как и сейчас, курс назывался Install, Configure, Manage (ICM). Добротный и весьма полный материал для подготовки молодых бойцов в сфере виртуализации.

Личный блог для самообучения

Все, что касается получения новой информации и знаний о виртуализации в целом, это достаточно интересная тема. Чем больше преподавательской деятельности я на себя брал, тем сильнее ощущалась потребность в новых, более глубоких знаниях.

В первое время мне за глаза хватало и тренинг-гайда: я мог прочитать его 10 раз и каждый раз находил что-то новое. Много времени я проводил с лабораторными машинами: разворачивал продукты, воспроизводил лабы, крутил их по-разному. Эта практика тоже оказалась очень полезной, я восполнял пробелы в базовых знаниях. Сейчас уже не вспомню: возможно, я читал какие-то англоязычные книги, но привычки их искать и изучать еще не было. Это пришло немного позже. Может быть, я тогда вообще ничего профильного со стороны не читал (смеется).

Затем я открыл для себя мир блогов. Они стали сами собой появляться по всему интернету: гуглишь что-то специфическое, и бац! выдается чей-то личный блог. Я перешел в фазу жадного поглощения информации и спустя короткое время оказался подписан буквально на десятки тематических блогов. Тогда я столкнулся со следующей проблемой: оказалось, недостаточно просто прочитать информацию, чтобы ее запомнить. Мне нужен был способ пропустить знания сквозь себя, выделить наиболее важные моменты и усвоить их. Так и возник мой собственный блог не из желания продвинуть свою фигуру, а чтобы важная информация откладывалась в голове через написание статей и заметок. Надо сказать, этот шаг тоже дался мне непросто. Все-таки, это публичное поле, новая ответственность :)

Работа преподавателем, с одной стороны, заставляла меня постоянно получать новые знания, с другой оставляла много свободного времени на учебу. Либо тренинги удавалось закончить немного пораньше, либо выдавались свободные недели, и я мог активно постить в блог. Можно сказать, я тогда занимался на 90% именно переработкой: публиковал короткое резюме-выдержку со ссылкой на оригинальную заметку.

Эта схема себя оправдала: со временем в блог подтянулась моя аудитория. Люди комментировали, задавали вопросы, даже уточняли что-то. Это давало много пищи для изучения. Забавно, что в какой-то момент я столкнулся с тем, что мне задают вопрос, я ищу ответ и нахожу его у себя же в блоге. Получалось, я забывал даже то, о чем сам писал.

Огонь в глазах, дискуссии и споры

Это, скорее, относится к курьезам, запоминающимся моментам. Есть такое устоявшееся выражение огонь в глазах. Применительно к моей практике преподавания это люди интересующиеся, жадные к знаниям. Есть и те, у кого этот огонь потух: к обучению они относятся, скорее, как к формальности.

С опытом я научился различать, к какой категории относятся те или иные мои слушатели. К моему удивлению, огонь далеко не всегда коррелирует с возрастом. Я видел и сонных молодых людей, которым ничего не интересно, и (почти) бабушек-дедушек, которые расспрашивали меня и действительно понимали, о чем идет речь на курсе. Я тогда решил, что дедушкой я хочу стать именно таким. Разумеется, не прямо сейчас, а с годами :)

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

Так я заметил еще один момент: в каждой группе между инициативными слушателями возникали дискуссии, споры. Я поощрял такие ситуации, даже говорил: Ребята, так получилось, что преподаватель здесь я, но у многих из вас есть опыт, которого нет ни у меня, ни у ваших коллег. Обменивайтесь этим опытом!. Наблюдая со стороны, я обратил внимание на то, что многие споры возникали из-за недопониманий между людьми. Два человека могли говорить об одном и том же, но разными словами. Или для обозначения разных понятий использовали одни и те же термины. Я старался всеми силами минимизировать такие ситуации, выводя спор в конструктивное русло. Дискуссии хороши, если обе стороны понимают друг друга и не пускаются в терминологические споры. Возможно, эта практика помогала людям учиться эффективнее и, в том числе, находила свое отражение в позитивных отзывах.

Мужики в свитерах: правда или вымысел?

Пару слов скажу о контингенте на моих курсах: на 98% процентов это были системные администраторы и инженеры заказчиков или интеграторов. Как правило, характеры у тех, кто представляет заказчиков, отличаются от тех, кто пошел на работу к интеграторам. Это, скорее, курьезное наблюдение, чем строгое. Что касается возраста были все, от молодежи до зрелых специалистов. Люди постарше приходили, конечно, реже.

Отвечая на ваш невысказанный вопрос да, девушки тоже бывали. Меньше, чем юноши, но в ИТ девушек в принципе меньше работает. Тем не менее, стабильный женский процент слушателей был всегда.

Когда в 2008-ом у меня вышла собственная книга и в узких кругах я стал Тем-Самым-Михаилом-С-Книжкой, я даже дежурно шутил: жаль, что в ИТ мало девушек. Приятно, конечно, когда бородатые мужики в свитерах пожимают тебе руку и говорят, какую классную книгу ты написал. Это льстит. Но все равно это бородатые мужики в свитерах

(На всякий случай еще раз поясню: это дежурная шутка!)

В качестве исключения были у меня и необычные слушатели, имевшие к ИТ опосредованное отношение. Изредка у интеграторов возникали ситуации, когда нужно кровь из носа обучить человека, но подходящих кадров под рукой нет. Таким ставленникам было сложно, но они все равно приходили, старались понять тему. Интересно, что большинство из них упорно сидели на курсах и даже пытались делать лабы. Им я максимально подробно объяснял, практически разжевывал материал делал скидку на непрофильный бэкграунд.

Как писалась книга

Книга это мой личный проект. Авантюра. Начав писать, я даже не был уверен, что смогу ее закончить. Но, как видите (улыбается). Сейчас я могу сказать, что книга оказала большое влияние на меня, на мою дальнейшую карьеру. Написать ее это решение, которым я до сих пор горжусь.

Я хорошо запомнил день, с которого все началось. Меня тогда отправили в командировку в Хабаровск как раз таки с курсами по VMware. Время от времени я летал с учебными задачами, в основном по отдаленным от Москвы местам: Казахстан, Баку, Дальний Восток. А длительный перелет это смена часовых поясов и неминуемый джет лаг.

Представьте себе: 4 часа утра. Гостиница, сна ни в одном глазу. Чтобы занять руки, отвечаю на вопрос читателя моего блога. Гуглю, чтобы уточнить информацию и попадаю... правильно, в собственный блог! Выходит, я все это знал, даже писал об этом, но забыл. За пониманием пришло озарение: а что, если я возьму и зафиксирую свои текущие знания в виде книги? Под рукой как раз была программа для составления mind mapов, в ней я начал накидывать приблизительное содержание про что и в каком порядке можно рассказать. Это был первый подход: крупные мазки, обширные планы.

Запала хватило на то, чтобы написать начало, а потом я стал перегорать. Не знаю, продвинулся бы я дальше, если бы не очередное удивительное совпадение. Спустя короткое время я поехал на конференцию VMware. Во время перерыва ко мне подошел представитель нишевого издательства: Вы Михаил Михеев? Очень приятно. Мне посоветовали обратиться к вам по поводу написания книги по теме виртуализации. Звезды сошлись: мысли о книге одновременно пришли в голову и мне, и издателю.

(Только сейчас понял, что забыл спросить у представителя издательства, кто указал ему именно на меня!)

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

Есть несколько воспоминаний из той поры:

• Издатель выдал набор правил оформления рукописи (подозреваю, что-то из области ГОСТов). А-ля пункты нумерованного списка должны заканчиваться точкой, а не-нумерованного точкой с запятой, кроме последнего, где тоже нужна точка. Запомнить все эти заморочки оказалось непросто, но в дальнейшем эти знания мне не раз пригодились.

• Скриншоты это сущий ад. На них уходила если не бльшая, то как минимум львиная доля времени. А в инструкции от издателя было указано: скриншоты сохраняйте в таком-то формате, притом обязательно черно-белые. Я люблю делать все по инструкции, поэтому не противился. И угадайте что? Оказывается, инструкция не учитывала существование электронных версий книг, где, очевидно, не имеет смысла черно-белить картинки. Подозреваю, издатель попросту не подумал об электронной книге (да-да, смешно звучит с высоты 2021 года). А для меня это обернулось повторным созданием почти всех скринов, так как исходники я почему-то не сохранял.

• Знали бы вы, как я стеснялся выложить анонс у себя в блоге. Очень сильно нервничал :)

Всего было три релиза: первый по 4-ой версии vSphere, второй по 4.1, а последний был посвящён уже 5-ой версии. Бумажные издания оформлены в разных цветах, чтобы читатели не путались.

Здесь важно понимать: моя книга это не художественное произведение. В ней нет героев и злодеев, только факты и темы, которые требуется осветить. По большому счету это учебник со всеми вытекающими из этого последствиями.

В свое время я шутил: мол, я написал самую лучшую книгу по VMware на русском языке. Знаете, почему? Потому что единственную, других нет.

В какой-то момент я увидел свою книгу на торрентах. Примерно в тех же раздачах, что и продукты VMware. Эмоции я испытал сложные. С одной стороны, по моему карману это не ударило. С другой было чуть-чуть обидно из за потери права распоряжаться своим детищем.

Один писатель-фантаст сказал: автор [в случае пиратства] теряет не столько деньги, сколько право распоряжаться плодом своего труда. В правовом поле автор может убрать свое произведение из конкретного магазина или вообще изъять из продажи. С условным торрентом это не так, это обидно. Вне зависимости от того, будешь ты что-то такое делать или нет.

Меня часто спрашивают, пишу ли я новую книгу. Короткий ответ нет. Чаще всего отшучиваюсь: мол, куда, у меня уже двое детей!

А если серьезно я и блог-то уже лет 7 не веду. Когда я был занят преподаванием, и блог, и книга были частью моей работы. В том числе, над собой. Моя текущая работа в VMware оставляет намного меньше времени на такие проекты. Честности ради в какой-то момент я предпринял еще одну попытку обновить книгу, но буквально через неделю понял: нет, не стоит этим заниматься. На предыдущем жизненном этапе у меня была четкая цель: что я хочу сделать, для кого и зачем. А книга ради книги это никому не интересно.

Сам собой назревает дискуссионный вопрос: вот я молодой, горящий специалист, есть ли мне смысл заявить о себе, написав книгу? [не суть важно, но, допустим, по решению VMware].

Выскажу свое мнение.

С одной стороны, сейчас у VMware есть продукты, по которым нет русскоязычных материалов. Так что смысл написать по ним книгу имеется, у специалистов она будет востребована. Но насколько велика будет аудитория? Вопрос открытый. К примеру, первый тираж моей книги составил порядка 5 тысяч экземпляров (за давностью могу ошибаться).

Это много или мало?

C другой стороны, старая добрая книга это уже немного олдскул. Есть блоги, есть YouTube. Есть Telegram-каналы, в конце концов. Может, лучше в эту сторону копнуть?

Готовогоответа у меня нет, но мне кажется, что классическая книга по-прежнему имеет смысл. Все-таки, когда ты говоришь: я Миша, автор [например] Telegram-канала такого-то или я автор такой-то книги, эффект получится разным.

Мой совет прислушайтесь к себе, постарайтесь понять задачу, которую хотите решить. Тогда вам станет ясно, каким способом подходить к решению: с помощью блога, канала или, к примеру, книги.

Как я попал в VMware

Наступил 2011 год. К тому моменту я уже имел около 6 лет преподавательского стажа. Популярность VMware и, соответственно, номенклатура курсов росли. Бывало так, что в течение месяца я мог читать один и тот же курс двум-трем разным группам.

С одной стороны, работа мне нравилась: я получал удовольствие от общения с людьми. Любил объяснять какие-то нетривиальные моменты. А с другой стал замечать, что прихожу на работу в понедельник, а голова включается только к среде. Рутина. Вышел к доске и пошел по накатанной: одни и те же слова, одни и те же шутки. Всем, вроде, нравится, а мне нет.

Потихоньку я начал искать варианты. Честно пошел к руководству учебного центра как раз тогда они активно знакомились с новыми боссами российского офиса VMware. И вышло так, что центр сам порекомендовал меня VMware.

Помнится, сижу я в больнице. Жду приема врача. Раздается звонок с незнакомого номера: оказалось, звонит руководитель пресейлов VMware. Предлагает пообщаться. Я тогда ничего не понял какую именно работу мне предлагают, чем я буду заниматься... Но все равно согласился на встречу.

По итогам собеседования меня приняли. В силу того, что в учебном центре существовал определенный горизонт планирования на пару месяцев вперед, когда набрана группа, составлен график, у слушателей куплены билеты и командировки, сразу же уйти я не мог. В VMware мне пошли навстречу, я доработал необходимый срок, съездил в небольшой отпуск в Питер и 13 февраля вышел на работу.

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

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

Значимую долю времени занимает обучение на внутренних и внешних курсах. Мир развивается, портфолио развивается, продукты обзаводятся новыми функциями и возможностями. Без обучения никак.

Кстати: еще в задачи пресейл-инженера входит обучение заказчиков и партнеров, а также выступления на различных мероприятиях. Например, в этом году наши пресейлы проводят цикл весенних вебинаров VMware 2021, которые будут идти до июня. На них можно не только послушать экспертов, но и пообщаться с ними в чатах и Q&A. Зарегистрироваться на вебинары можно на сайте, а посмотреть онлайн-мероприятия в записи на нашем YouTube-канале. А для энтузиастов у нас есть канал в Telegram: там мы напоминаем о старте вебинаров и делимся видео.

Спустя несколько лет мне предложили стать тимлидом группы пресейлов. Людей в отделе становилось все больше и больше, и в одиночку решать все менеджерские проблемы нашему начальнику становилось тяжело. Время в сутках ограничено.

Как водится, решение пойти в эту область не было для меня легким. Другие задачи, другая ответственность, потенциально иные отношения с коллегами. В новые обязанности мне удалось войти не спеша, совмещая их с работой пресейла. Более того, я по прежнему прикладываю усилия чтобы оставаться одной ногой на земле. Оторваться всегда легко, а вернуться обратно, как говорят старшие товарищи, невозможно.

Немного об изоляции

У нас переход на полную удаленку прошел очень гладко. Иногда мы с коллегами обмениваемся опытом, у кого и как оборудовано рабочее место.

У части нашего коллектива, например, у меня, есть дома съемный зеленый экран и штатив для камеры. На Хабре были статьи об организации рабочих мест в части аудио- и видеосвязи. Многое я почерпнул именно оттуда. Я даже телесуфлером обзавелся, чтобы в домашних условиях делать записи попрофессиональнее.

Сотрудники VMware в России это такие же люди, как и везде. Нам тоже не хватает встреч лицом к лицу и в коллективе, и при решении вопросов с заказчиками. Удаленка это нормально, это правильно сейчас. Но я все равно жду момента, когда мы сможем хотя бы какой-то процент времени тратить на очные встречи.

Кто востребован в VMware

Наверное, я сейчас скажу не самую очевидную вещь. Нам не особо важно, является ли человек экспертом в продуктах VMware. Этому мы как раз можем научить на месте: и ресурсов, и учебных материалов, и опыта у нас достаточно. Любые ИТ-продукты это не квантовая физика. Получить нормальную или даже отличную экспертизу в них можно. Главное воспринимать это не как проблему, а как задачу. Попробовал получилось. Поотвечал на вопросы и сам не заметил, как освоил тему.

Гораздо сложнее научить человека soft-скиллам и такому навыку, как доведение дел до конца. Работы больше, чем времени в сутках, поэтому всегда есть соблазн что-то здесь поделать, там поковырять, но до конца не доводить. Льется нескончаемый поток задач, и ты думаешь: я буду что-то отдельное выхватывать. Это не очень хорошая история. Если уж взялся делай. Не берешься скажи. Не оставляй повисшим в воздухе.

Один из главных soft-скиллов уметь говорить на языке собеседника. Отличным примером является известный в хаброкругах Milfgard. Помните шикарную статью про недочеты в унаследованной архитектуре живых существ? Огонь же! И в том числе потому, что материал подан на языке читательской аудитории.

Вернемся к теме. При всем вышесказанном айтишный бэкграунд иметь все-таки желательно. Научить продуктам можно, но если вообще никакого бэкграунда нет, это может стать большой проблемой. С другой стороны, нам бывают нужны люди с разным рабочим опытом. Где-то сетевой бэкграунд более важен, где-то менее, например.

Из очевидных требований сотруднику необходим разговорный английский. VMware мировая компания, на ежедневной основе люди работают в интернациональных группах, обращаются за консультацией или помощью к западным коллегам. По-моему, это здорово, когда ты в рамках рабочего общения можешь поговорить с крутыми людьми, представителями родственной профессии, живущими в другой стране или даже части мира. Прикоснуться к их культуре, менталитету. Незабываемый опыт. Отдельная приятность прямой доступ к Product Managerам, которые непосредственно отвечают за развитие продуктов (нередко прямо в Кремниевой долине, с географической точки зрения). Лично мне очень импонирует возможность обратиться к первоисточникам, а то и пригласить их на конф-колл по проекту с заказчиком.

Немного о Хабре

Хабр для меня один из главных источников информации из разных сфер.

Например, актуальны были несколько статей про организацию видеозвонков, вот эту даже в Evernote себе сохранил и по ее заветам приспособил старый телефон в качестве веб-камеры.

Просто просмотр заголовков статей в RSS-клиенте позволяет составить мнение о событиях мира ИТ в целом.

Очень интересны статьи про собеседования с обеих сторон. У меня есть собственный список вопросов для обсуждения на собеседовании, и я периодически вношу в него изменения, если встречаю интересный вопрос, подход или какой-то инструмент для проведения собеседования.

Обязательно читаю статьи Milfgardа. Во-первых, он в принципе хорошо складывает слова в приложения. Во-вторых, он хорошо умеет разговаривать на языке аудитории. Это крутая тема, близкая мне и по работе преподавателем, и по нынешней. Его статью Вы неправильно пишете животных я даже перечитываю для удовольствия иногда, круто написана и оптимизирована под ИТ.

Ну и нельзя не сказать, что именно с его статьи Настольные игры: во что играют в IT-офисах? от далекого 2011 года началось мое нынешнее увлечение настольными играми, в котором я весьма глубоко погряз :)

Друзья! Если вам интересен такой формат, будем рады вашим пожеланиям. Поделитесь в комментариях, интервью с представителями каких сфер и профессий вам бы хотелось видеть на Хабре.

Но, разумеется, это далеко не все, чем нам запомнилась самая масштабная ИТ-конференция года. Те, кто следит за нашими социальными сетями, наверняка знают о том, что в течение всего события мы освещали его ключевые моменты и брали интервью у экспертов VMware. Под катом короткий список самых примечательных анонсов VMworld 2020.

Год перемен

Вряд ли хоть один спикер обошел вниманием сложность и необычность уходящего года. Множество докладов было сосредоточено вокруг тем здравоохранения, включая разработку вакцины от COVID-19, безопасности, удаленной работы и обучения. Спикеры подчеркнули, что в насыщенном технологиями современном мире именно ИТ позволяет сохранять накопленный опыт и двигаться вперед.

Крис Вольф, вице-президент VMware, ввел новое значение термина выносливость применительно к бизнес-сообществу: теперь это не просто способность справляться с повышенными нагрузками, но и умение адаптироваться к меняющимся условиям, сохраняя свою целостность. Девиз VMworld 2020 Когда мы вместе, все становится возможным (Together, Anything is Possible).

Так, именно технологии сделали возможным проведение крупнейшего ИТ-мероприятия в режиме онлайн. Более 900 сессий, десятки анонсов, сотни спикеров и даже мини-спектакль с участием голливудской звезды. Разберемся по порядку.

Безопасность и сети

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

VMware SASE Platform

Первый продукт, о котором мы сегодня расскажем, VMware SASE Platform. Задача решения обеспечить сотрудников компаний инструментами сетевой безопасности в любом месте, где бы они ни находились. VMware SASE Platform базируется на VMware SD-WAN массиве, состоящем из более чем 2700 облачных узлов в 130 точках входа.

В основе VMware SASE Platform лежат следующие компоненты и принципы:

• Непосредственно VMware SD-WAN.

• Cloud Access Service Broker (CASB), Secure Web Gateway (SWG) и удаленная изоляция браузера.

• VMware NSX Stateful Layer 7 Firewall.

• Концепция безопасности Zero Trust во главе угла стоит идентификация конечного пользователя и его устройств при каждом подключении.

• Edge Network Intelligence машинное обучение используется для предиктивного анализа и обеспечения безопасности как конечных пользователей, так и IoT-устройств.

Наряду с VMware SASE Platform стоит поговорить и о других инновациях компании.

VMware Workspace Security Remote

Это интегрированное решение для обеспечения безопасности, администрирования и удаленной ИТ-поддержки конечных устройств. Включает антивирусную защиту, аудит и устранение неполадок, а также функционал Carbon Black Workload по обнаружению и реагированию на угрозы.

VMware NSX Advanced Threat Prevention

Брандмауэр для защиты east-west трафика в многооблачных средах на базе машинного обучения. Служит для распознавания угроз и сокращения числа ложных срабатываний.

Также было анонсировано несколько новых решений из сетевого портфеля VMware:

• VMware Container Networking with Antrea продукт для управления сетевым взаимодействием контейнеров в виртуальной среде.

• NSX-T 3.1 расширение возможностей маршрутизации на базе API, автоматизированное развертывание процессов с помощью Terraform Provider.

• VMware vRealize Network Insight 6.0 проверка и контроль качества сети на базе модели ее работы.

VMware Carbon Black Cloud Workload

Решение было анонсировано в виде планируемой технологии еще в прошлом году. Его задача обеспечение безопасности виртуальных машин на vSphere.

Кроме того, в VMware vCenter теперь будут встроенные инструменты для визуализации рисков, подобные тем, что уже есть в Carbon Black Cloud.

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

VMware Workspace Security VDI

VMware Workspace ONE Horizon и VMware Carbon Black Cloud интегрированы в единое решение. Решение использует поведенческий анализ для защиты от вымогателей и бесфайловых вредоносов. В VMware vSphere оно доступно через VMware Tools. Больше нет необходимости устанавливать и настраивать агенты безопасности отдельно.

Приоритеты в мультиоблачности

Мультиоблачность один из ключевых векторов VMware. Тем не менее, многим компаниям с трудом дается переход даже в одно облако. Возникают сложности с вопросами безопасности и связности различных разрозненных решений. Закономерно, что бизнес боится появления такого хаоса сразу в нескольких облачных средах. Стратегия VMware в ключе мультиоблака призвана помочь заказчикам решить проблемы унификации средств и процессов.

Azure VMware Solution

Компания уже оставила заметный след в таких крупных публичных облаках, как AWS, Azure, Google Cloud, IBM Cloud и Oracle Cloud.

Azure VMware Solution позволит бизнесу сэкономить за счет гибридного использования Azure, интеграции с Microsoft Office 365 и других нативных сервисов Azure.

VMware Cloud on AWS

Новые возможности появились и в VMware Cloud on AWS. Среди них:

• VMware Cloud Disaster Recovery.

• Поддержка VMware Tanzu.

• VMware Transit Connect.

• Улучшения в области автоматизации: расширение поддержки vRealize Operations, Cloud Automation, Orchestrator, Log Insight and Network Insight support.

• Расширенные возможности HCX: vMotion с поддержкой репликации, локальная маршрутизация для мигрированных ВМ, а также группировка миграция.

Project Monterey

Без сомнения, это один из самых интересных проектов VMware из числа анонсированных на VMworld 2020. Фактически, Project Monterey логическое продолжение технологии Project Pacific для инфраструктуры VMware Cloud Foundation, только теперь с акцентом на железо.

Миссия проекта состоит в том, чтобы реорганизовать и переработать архитектуру VCF для интеграции новых аппаратных возможностей и компонентов ПО. Сообщается, что благодаря SmartNIC VCF сможет поддерживать исполнение программ и ОС без гипервизора, то есть на чистом железе. Выделим следующие основные моменты:

• Увеличение пропускной способности и уменьшение задержек за счет переноса сложных сетевых функций на железный уровень.

• Унифицированные операции для всех типов ПО, включая bare-metal ОС.

• Возможность изоляции приложений без уменьшения их производительности благодаря применению модели Zero-trust security.

Если проект вас заинтересовал, рекомендуем прочитать (на английском) эту статью.

VMware vRealize AI

Еще в 2018 году сообществу был представлен Project Magna. На минувшей конференции основной функционал проекта стал доступен в качестве VMware vRealize AI. Решение использует обучение с подкреплением для самонастройки производительности приложений. Оптимизация кэша чтения и записи в средах vSAN с помощью vRealize AI позволила на 50% повысить производительность операций ввода-вывода, включающих чтение и запись.

Inside the Tanzu Portfolio

С серьезными новостями покончено, и мы переходим к развлекательному контенту. В рамках сессии Inside the Tanzu Portfolio была продемонстрирована короткая романтическая комедия, включавшая кадры с актрисой Рене Зеллвегер. Эксперты VMware решили, что игровой формат позволит продемонстрировать новые возможности Tanzu и немного развлечет зрителей, подключившихся к конференции онлайн. Разумеется, воспринимать эту трансляцию на 100% серьезно не стоит это не академический материал, а простое объяснение портфеля решений, составляющих Tanzu.

Говоря кратко, Tanzu представляет собой новый бренд, под капотом которого находится целый комплекс ПО для разработчиков, призванный облегчить их труд на всех этапах жизненного цикла приложения. В частности, продукты Tanzu решают ключевые вопросы построения приложений, менеджмента, обеспечения безопасности, отказоустойчивости и сосредоточены вокруг работы с контейнерами Kubernetes. Рекомендуем трансляцию к просмотру продуктологам и менеджерскому составу компаний.

Virtual Data Therapy PuppyFest

Компания Commvault, золотой партнер компании VMware, продемонстрировала полусерьезный ролик о защите данных под слоганом Dont let your data go to the dogs Не допустите, чтобы ваши данные пошли псу под хвост.

Примечательно, что после трансляции основного видеоматериала был открыт живой чат с представителями команды Puppy Love компании, которая занимается передачей спасенных собак в добрые руки. Практически любой зритель из США мог в ходе сессии не только задать интересующие технические вопросы, но и обзавестись четвероногим другом.

Что же в итоге?

VMworld 2020, без преувеличения, знаковое событие на технологической арене. Если бы оно не состоялось, это значило бы, что у нашего мира начались по-настоящему тяжелые дни. Но, как оптимистично заявляет Пэт Гелсингер, CEO VMware, игра продолжается. Новые трудности подстегивают нас на создание новых способов борьбы с ними. Жизнь идет своим чередом пандемия понемногу отступит, а багаж знаний и опыта, накопленный за месяцы изоляции, останется с нами и послужит надежным подспорьем для создания чего-то нового, крутого и интересного.

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

По традиции скажем: оставайтесь на связи и обязательно послушайте выпуски нашего подкаста IaaS без прикрас, посвященные VMworld 2020. На Яндекс Музыке, Anchor и YouTube доступны:

• VMworld 2020: Генеральная сессия, мультиоблака и стратегия VMware

• VMworld 2020: Стратегия безопасности, SD-WAN, SASE и будущее сетей

• VMworld 2020: Kubernetes, Tanzu Portfolio и что нового в vSphere 7

Будущих учащихся на курсе "Infrastructure as a code in Ansible", а также всех желающих приглашаем принять участие в открытом вебинаре на тему "Управление Kubernetes при помощи Kubespray".

И по устоявшейся традиции делимся с вами переводом полезной статьи.

Terraform это потрясающее средство для автоматизации управления инфраструктурой. Все параметры вашей инфраструктуры можно записать в виде кода, который будет обслуживаться соответствующей группой. Это означает, что ваша инфраструктура будет прозрачной и не будет подвержена неожиданным изменениям.

Первоначально опубликовано в блоге techbeatly; там же доступны другие статьи по теме.

Читайте также:Программа обучения и советы по прохождению экзамена HashiCorp Certified Terraform Associate.

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

Шаг 1. Получение сведений о существующей виртуальной машине из VMWare vCenter

Выполните вход в VMWare vCenter и найдите данные виртуальной машины. Вам потребуются такие данные, какцентр обработки данных,папка виртуальной машины,имя виртуальной машины,ЦП,память,диски т.д.

Если у вашей виртуальной машины есть особые параметры конфигурации, например дополнительные диски, дополнительные сетевые адаптеры или нестандартные аппаратные характеристики, обязательно укажите их в коде Terraform.

Шаг 2. Создание кода Terraform для существующей виртуальной машины

В Terraform нет возможности импортировать существующую инфраструктуру в код Terraform. Вместо этого приходится писать конфигурацию Terraform, соответствующую имеющейся инфраструктуре, и импортировать ее.

Ниже приведен код Terraform, который я написал для виртуальной машины со следующим путем и именем:/DC1/vm/DEV/DEV2.

См. содержимое файлаvmware-import-vm.tf.

provider "vsphere" {  user           = var.vsphere_user  password       = var.vsphere_password  vsphere_server = var.vsphere_server  # If you have a self-signed cert  allow_unverified_ssl = true}data "vsphere_datacenter" "dc" {  name = "DC1"}data "vsphere_datastore" "datastore" {  name          = "datastore1"  datacenter_id = data.vsphere_datacenter.dc.id}data "vsphere_compute_cluster" "cluster" {  name          = "AZ1"  datacenter_id = data.vsphere_datacenter.dc.id}data "vsphere_network" "network" {  name          = "VM Network"  datacenter_id = data.vsphere_datacenter.dc.id}resource "vsphere_virtual_machine" "vm" {  name             = "DEV2"  resource_pool_id = data.vsphere_compute_cluster.cluster.resource_pool_id  datastore_id     = data.vsphere_datastore.datastore.id  wait_for_guest_net_timeout = 0  wait_for_guest_ip_timeout  = 0  # only if you DO NOT want to wait for an IP address  wait_for_guest_net_routable = false  num_cpus = 1  memory   = 2048  #guest_id = "other3xLinux64Guest"  network_interface {    network_id = data.vsphere_network.network.id  }    disk {    label            = "disk0"    size             = 20    thin_provisioned = false  }}

Я также объявил несколько переменных для передачи учетных данных VMWare.

$ cat variables.tf variable "vsphereuser" {}variable "vspherepassword" {}

В этом примере я передаю свои учетные данные VMWare vCenter с помощью переменных среды (см. пример ниже).

$ export TFVARvsphereuser='Administrator@lab.local'$ export TFVARvspherepassword='mypassword'

Шаг 3. Инициализация кода Terraform

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

$ terraform initInitializing the backend...Initializing provider plugins...- Finding latest version of hashicorp/vsphere...- Installing hashicorp/vsphere v1.24.2...- Installed hashicorp/vsphere v1.24.2 (signed by HashiCorp)The following providers do not have any version constraints in configuration,so the latest version was installed.To prevent automatic upgrades to new major versions that may contain breakingchanges, we recommend adding version constraints in a required_providers blockin your configuration, with the constraint strings suggested below.* hashicorp/vsphere: version = "~> 1.24.2"Terraform has been successfully initialized!You may now begin working with Terraform. Try running "terraform plan" to seeany changes that are required for your infrastructure. All Terraform commandsshould now work.If you ever set or change modules or backend configuration for Terraform,rerun this command to reinitialize your working directory. If you forget, othercommands will detect it and remind you to do so if necessary.

Проверим текущее состояние, управляемое Terraform:

$ terraform showNo state.

Да, мы пока еще не выполнили запуск.

Примечание. Что произойдет, если я выполню командуterraform apply? Все просто, система попытается выделить ресурсы для виртуальной машины, но эта попытка завершится ошибкой. Система сообщит, что виртуальная машина с именемDEV2уже существует. Как бы то ни было, в данном примере это не наш случай.

Шаг 4. Импорт виртуальной машины в состояние Terraform

Итак, теперь все готово к импорту имеющейся у нас виртуальной машины в состояние Terraform.

$ terraform import vsphere_virtual_machine.vm /DC1/vm/DEV/DEV2vsphere_virtual_machine.vm: Importing from ID "/DC1/vm/DEV/DEV2"...vsphere_virtual_machine.vm: Import prepared!  Prepared vsphere_virtual_machine for importvsphere_virtual_machine.vm: Refreshing state... [id=4219040f-5842-ba52-b7e4-cd9064c1f36c]Import successful!The resources that were imported are shown above. These resources are now inyour Terraform state and will henceforth be managed by Terraform.

Готово, теперь наша виртуальная машина часть состояния Terraform, и ей можно управлять изTerraform, выполняя такие операции, как добавление нового интерфейса, нового жесткого диска и т.д.

Это можно проверить, выполнив командуterraform showеще раз.

$ terraform show# vsphere_virtual_machine.vm:resource "vsphere_virtual_machine" "vm" {    boot_delay                              = 0    boot_retry_delay                        = 10000    boot_retry_enabled                      = false    change_version                          = "2020-11-03T08:33:13.180937Z"    cpu_hot_add_enabled                     = false    cpu_hot_remove_enabled                  = false    cpu_limit                               = -1    cpu_performance_counters_enabled        = false    cpu_reservation                         = 0    cpu_share_count                         = 1000    cpu_share_level                         = "normal"    custom_attributes                       = {}    datastore_id                            = "datastore-13"    efi_secure_boot_enabled                 = false    enable_disk_uuid                        = false    enable_logging                          = true    ept_rvi_mode                            = "automatic"    extra_config                            = {}    firmware                                = "bios"    folder                                  = "DEV"    force_power_off                         = true    guest_id                                = "rhel7_64Guest"    guest_ip_addresses                      = []    hardware_version                        = 14    host_system_id                          = "host-12"    hv_mode                                 = "hvAuto"    id                                      = "4219040f-5842-ba52-b7e4-cd9064c1f36c"    ide_controller_count                    = 2    imported                                = true    latency_sensitivity                     = "normal"    memory                                  = 2048    memory_hot_add_enabled                  = false    memory_limit                            = -1    memory_reservation                      = 0    memory_share_count                      = 20480    memory_share_level                      = "normal"    migrate_wait_timeout                    = 30    moid                                    = "vm-47"    name                                    = "DEV2"    nested_hv_enabled                       = false    num_cores_per_socket                    = 1    num_cpus                                = 1    pci_device_id                           = []    poweron_timeout                         = 300    reboot_required                         = false    resource_pool_id                        = "resgroup-8"    run_tools_scripts_after_power_on        = true    run_tools_scripts_after_resume          = true    run_tools_scripts_before_guest_reboot   = false    run_tools_scripts_before_guest_shutdown = true    run_tools_scripts_before_guest_standby  = true    sata_controller_count                   = 1    scsi_bus_sharing                        = "noSharing"    scsi_controller_count                   = 1    scsi_type                               = "pvscsi"    shutdown_wait_timeout                   = 3    swap_placement_policy                   = "inherit"    sync_time_with_host                     = false    tags                                    = []    uuid                                    = "4219040f-5842-ba52-b7e4-cd9064c1f36c"    vapp_transport                          = []    vmware_tools_status                     = "guestToolsRunning"    vmx_path                                = "DEV2/DEV2.vmx"    wait_for_guest_ip_timeout               = 0    wait_for_guest_net_routable             = true    wait_for_guest_net_timeout              = 5    cdrom {        client_device  = false        datastore_id   = "datastore-13"        device_address = "sata:0:0"        key            = 16000        path           = "ISO/rhel-server-7.7-x86_64-dvd.iso"    }    disk {        attach           = false        controller_type  = "scsi"        datastore_id     = "datastore-13"        device_address   = "scsi:0:0"        disk_mode        = "persistent"        disk_sharing     = "sharingNone"        eagerly_scrub    = false        io_limit         = -1        io_reservation   = 0        io_share_count   = 1000        io_share_level   = "normal"        keep_on_remove   = true        key              = 2000        label            = "disk0"        path             = "DEV2/DEV2.vmdk"        size             = 20        thin_provisioned = false        unit_number      = 0        uuid             = "6000C29b-c4f0-764a-9054-a042931350c4"        write_through    = false    }}

Заключение

Если вы планируете управлять конфигурацией внутри операционной системы виртуальной машины, помните о том, что нужно использовать соответствующиесредства выделения ресурсов (provisioners).

Подробные сведения см. в документации по ресурсу vsphere_virtual_machine.

Полный код приведен на GitHub в репозиторииterraform-vmware-demos.

Узнать подробнее о курсе "Infrastructure as a code in Ansible".

Зарегистрироваться на открытый урок на тему "Управление Kubernetes при помощи Kubespray".

ЗАБРАТЬ СКИДКУ

Вложенная виртуализация позволяет запускать гипервизор внутри виртуальной машины. Это необходимо, чтобы не экспериментировать на боевой системе, рискуя уронить всё и сразу, а потом долго и мучительно поднимать её под добрые слова коллег о прямизне конечностей и чьей-то матери. Если вы хотите потестить вложенную виртуализацию, изучите наш туториал.

Перед вами пошаговое руководство по подготовке шаблона vApp для VMware Cloud Director, включающего в себя vCenter Server Appliance и 3 гипервизора ESXi, с целью снижения временных затрат на развертывании тестовой инфраструктуры VMware.

1. Что мы будем делать

Мы подготовим максимально гибкий шаблон без привязки к адресу подсети, доменному имени, количеству выделяемых ресурсов и т.п. Будем делать так, чтобы при развертывании шаблона администратор мог произвести тонкую настройку. Подготовка шаблона выполняется в сети 10.0.0.0/24, а за стандартные значения при развертывании готового шаблона примем домен Domain.local и сеть 192.168.2.0/24.

Имя домена domain.local и сеть 192.168.2.0/24 выберем как значения по умолчанию, которые можно изменять в процессе развёртывания шаблона.

Мы подготовим шаблон, включающий в себя 6 виртуальных машин.

1.1. Список VM в шаблоне

1. VMware ESXi 1 Гипервизор;

2. VMware ESXi 2 Гипервизор;

3. VMware ESXi 3 Гипервизор;

4. VMware vCenter Server Appliance with Embedded Platform Services Controller в конфигурации Tiny;

5. Ubuntu 18.04 LTS в качестве общего NFS хранилища;

6. Windows Server 2019 в качестве DNS сервера и Management machine. В последствии, с нее будет производится управления vCenter.

1.2. Требования

1. VDC в VMware Cloud Director:

   a. 28 vCPU;

   b. 50GB RAM;

   c. 2TB Storage.

2. Дистрибутивы ПО:

   a. ISO с дистрибутивом VMware ESXi 6.7U3b;

   b. ISO (или OVA) с дистрибутивом VMware vCenter Server Appliance 6.7U3b;

   c. ISO (или OVA) с Windows Server 2019;

   d. ISO (или OVA) с Ubuntu1804.

3. Дополнительное ПО (опционально):

   a. Браузер Google Chrome;

   b. Текстовый редактор Notepad++;

   c. SFTP клиент WinSCP.

   d. 7-Zip

4. Убедитесь, что в нашей локальной сети на уровне vCenter облачного провайдера переключены в состоянии Accept политики Promiscuous mode и Forged transmits. Иначе не будет связи между сетью виртуального дата-центра и сетью внутри подготавливаемого шаблона. Здесь об этом рассказывается подробнее.

Дистрибутивы продуктов VMware можно скачать с официального сайта, зарегистрировавшись в программе обучения и получив VMware Evaluation License на 60 дней.

Возможностей VMware Cloud Director для подготовки данного шаблона будет недостаточно, поэтому сначала развернём нашу рабочую среду Working Environment в виртуальном дата-центре VMware Cloud Director.

В рабочую среду мы установим ESXi гипервизор, vCenter Server Appliance и Windows Server 2019 в качестве ManagementVM. Подготовку шаблона будем выполнять, используя интерфейс vSphere Client в рабочей среде.

2. Схема логической топологии

3. Подготовка Working Environment

3.1. Установка ESXi

В VDC создаём каталог (Libraries -> Catalogs -> New) и загружаем в него ISO с установщиком ESXi.

Создаём VM temp-ESXi1 ESXi 6.7.

Выбираем загрузку с ISO.

Назначаем VM 24 vCPU, 24 Cores per socket, 32GB RAM и 5GB Storage. Подключаем сеть к виртуальной машине.

ESXi требует для развёртывания минимум двухъядерные процессоры. Установка на 24 одноядерных vCPU завершится ошибкой, поэтому необходимо задать отличный от единицы параметр Cores per socket.

Запускаем VM.

Выполняем установку, нажимая Enter или F11

В процессе установки задаём пароль root

Нажимаем F11 и дожидаемся завершения установки

По завершению установки нажимаем Enter и перезагружаемся

Дожидаемся окончания загрузки, нажимаем F2, вводим пароль root

Переходим в настройки сети Configure Management Network.

Задаём статический IP.

Отключаем IPv6.

Перезагружаем VM для применения отключения IPv6. Для применения остальных настроек достаточно перезапуска сетевого адаптера.

В VMware Cloud Director подключаем к temp-ESXi1 ещё один диск на 1ТБ. Это будет наш Datastore. Перезагружаем VM temp-esxi1.

3.2. Установка ManagementVM

Разворачиваем VM с Windows Server 2019. Настраиваем доступ по RDP.

Подключаемся по RDP к VM c Windows Server. Устанавливаем роль DNS сервера.

Создаём Forward Lookup Zone template.local

Создаём Reverse Lookup Zone для 0.0.10.in-addr.arpa

Создаём A и PTR записи в созданных зонах для temp-esxi01 и vcentersa1.

Важно! PTR запись для vCenter должна быть обязательно. Без неё установка vCenter завершится ошибкой.

Настраиваем DNS Forwarders.

Настраиваем DNS сервер 127.0.0.1 на сетевом интерфейсе.

3.3. Установка vCenter Server Appliance

Монтируем образ VMware-VCSA-all-6.7.0-14367737.iso на ManagementVM и извлекаем из ISO E:\vcsa\VMware-vCenter-Server-Appliance-6.7.0.40000-14367737_OVF10.ova

Переходим в vcd.cloud4y.ru в свой VDC. Загружаем в каталог OVA шаблон с vCenter. Для загрузки понадобится 300 ГБ свободного места в VDC.

Получаем ошибку

В логе видим текст ошибки Validation failed for the OVF file you provided: Fatal: Line/char 867/92: cvc-minInclusive-valid: Value '-100' is not facet-valid with respect to minInclusive '0' for type 'unsignedShort'. Fatal: Line/char 867/92: cvc-attribute.3: The value '-100' of attribute 'ovf:id' on element 'OperatingSystemSection' is not valid with respect to its type, 'unsignedShort'..

VMware Cloud Director не принимает значение -100 на строке 867 *.ovf файла.

Возвращаемся на ManagementVM и с помощью архиватора 7-zip извлекаем *.ovf и *.mf файлы. OVA представляет из себя архив tar, и, как правило, содержит файлы виртуальных дисков *.vmdk, файл конфигурации VM/vApp *.ovf, список файлов в архиве и их контрольные суммы *.mf

Открываем *.ovf через текстовый редактор и ищем -100 на 867 строке и заменяем на 1

Теперь нам нужно пересчитать SHA1 для *.ovf файла и изменить это значение в *.mf файле

Для расчета хеша используем PowerShell

(Get-FileHash C:\Users\Administrator\Desktop\VMware-vCenter-Server-Appliance-6.7.0.40000-14367737_OVF10.ovf -Algorithm SHA1).Hash.ToLower()

Заменяем значение в *.mf файле

Запаковываем *.ovf и *.mf обратно в OVA шаблон

Пробуем загрузить OVA в VDC ещё раз.

По завершению загрузки разворачиваем vApp с vCenter в нашем VDC

Выделяемые ресурсы vCPU, RAM, Storage не меняем. Больше ресурсов не требуется, а при меньшем значении могут возникнуть проблемы с производительностью.

Конфигурируем сеть.

На шаге 8 ничего не меняем. Мы изменим эти параметры позже. Нажимайте Next. Если при развёртывании шаблона что-то пойдёт не так, придётся заполнять эти поля ещё раз при повторном развёртывании.

Дожидаемся окончания развёртывания и перемещаем VM в vApp vcsa + esxi для наглядности. С технической точки зрения разницы нет.

По окончанию перемещения наш vApp vcsa + esxi выглядит следующим образом.

Переходим в Guest Properties temp-vcentersa1 и нажимаем Edit

Заполняем поля, указанные в таблице ниже. Остальные поля заполнять не обязательно

На случай, если мы где-то ошиблись в заполнении параметров, можно создать Snapshot перед первым запуском.

Запускаем VM и ждём 5-10 минут.

Через браузер с ManagementVM переходим на https://temp-vcentersa1.template.local:5480/ и дожидаемся окончания установки.

Нажимаем Set Up

Вводим пароль root, указанный ранее в Guest Properties

На шаге 2 проверяем корректность настроек. Редактируем при необходимости.

На шаге 3 создаём новый SSO домен.

Проверяем корректность параметров и нажимаем Finish.

Если установка завершится ошибкой на 2%, то проблема почти наверняка кроется в некорректно созданной PTR записи для vCenter.

Дожидаемся окончания установки

Переходим по адресу https://temp-vcentersa1.template.local:443, выбираем LAUNCH VSPHERE CLIENT (HTML5)

Вводим учётные данные Администратора SSO домена

Скачиваем сертификат CA и устанавливаем в систему https://temp-vcentersa1.template.local/certs/download.zip .

Необходимо установить сертификат download.zip\certs\win\*.crt в доверенные корневые центры сертификации ManagementVM и перезапустить браузер.

В vCenter создаём дата-центр.

В дата-центре создаём кластер.

Включаем vSphere DRS.

vSphere HA и VSAN оставляем выключёнными. C 1 ESXi гипервизором DRS работать не будет, но он должен быть включён для работы с vApp.

Переходим в Configure - > Configuration > Quickstart кластера temp-Cluster и добавляем temp-ESXi1, нажав ADD.

Выбираем наш хост temp-esxi1.template.local и вводим учётные данные root.

Принимаем его сертификат и завершаем работу с Quickstart. Нужно добавить temp-esxi1 в кластер. Продолжать настройку кластера необходимости нет.

Добавляем Datastore в наш кластер. Кликаем правой кнопкой мыши по кластеру и выбираем Storage -> New Datastore.

Выбираем тип VMFS

Задаём имя Datastore и выбираем подключенный ранее диск на 1 ТБ на temp-ESXi1.

На шаге 4 указываем использование всего раздела на 1 ТБ и завершаем работу мастера.

Выводим temp-esxi1 из Maintenance Mode

Подготовка инфраструктуры для создания шаблона завершена.

4. Создание шаблона vApp

4.1. Подготовка vApp

Кликаем на кластер правой кнопкой мыши и создаём новый vApp: vApp_vCenter6.7_3ESXi6.7_UbuntuNFS_WindowsDNS

В vApp будут следующие VM:

1. ESXi01

2. ESXi02

3. ESXi03

4. vCenterSA01

5. WindowsDNS

6. UbuntuNFS01

UbuntuNFS это имитация внешней СХД. На ней будет Datastore, доступный всем ESXi хостам.

ESXi0x устанавливаем из ISO. vCenterSA01, WindowsDNS, UbuntuNFS можно развернуть из OVA шаблонов.

Добавим ISO с установщиком ESXi в temp-Datastore. Переходим в Datastores -> temp-Datastore -> Files, создаём папку ISO и загружаем в неё ISO образ установщика ESXi

4.2. Создание ESXi VM в vApp

На шаге 2 задаём имя VM.

На шаге 3 выбираем vApp, в котором будут размещены VM.

На шаге 6 выбираем тип гостевой ОС.

На шаге 7 выбираем 2 vCPU, 4GB RAM, 5GB Storage и подключаем ISO. Разверните подраздел CPU и отметьте пункт Hardware virtualization.

Перейдите на вкладку VM Options и снимите отметку с пункта Secure Boot.

Клонируем VM ESXi01 в VM ESXi02 и в VM ESXI03.

Запускаем vApp и выполняем установку ESXi01, ESXi02, ESXi03.

Настраиваем на ESXi IP адреса:

ESXi01 - 10.0.0.11

ESXi02 - 10.0.0.12

ESXi03 - 10.0.0.13

На каждом ESXi хосте включаем доступ по SSH (F2 -> Troubleshooting Options - > Enable SSH)

4.3. Кастомизация ESXi в vApp

Добавим ESXi хостам возможность кастомизации сетевых параметров из интерфейса VMware Cloud Director (и vSphere Client). Для этого подключимся с помощью WinSCP к хосту, перейдём в каталог /etc/rc.local.d и откроем текстовым редактором файл local.sh

Заменим содержимое local.sh следующим скриптом:

#!/bin/sh#Customization script for ESXi01getprops_from_ovfxml() {/bin/python - <<EOSfrom xml.dom.minidom import parseStringovfEnv = open("$1", "r").read()dom = parseString(ovfEnv)section = dom.getElementsByTagName("PropertySection")[0]for property in section.getElementsByTagName("Property"):key = property.getAttribute("oe:key").replace('.','_')value = property.getAttribute("oe:value")print ("{0}={1}".format(key,value))dom.unlink()EOS}#С помощью VMware Tools получаем ovf.xml с параметрами, переданными через Guest Properties/sbin/vmtoolsd --cmd='info-get guestinfo.ovfEnv' >/tmp/ovf.xml 2>/dev/nulleval `getprops_from_ovfxml /tmp/ovf.xml`#Проверяем, что в Guest Properties включена кастомизацияif [ $enablecustomization1 = "enabled" ] ;thenesxcfg-init --set-boot-progress-text "Applying OVF customization..."#Изменяем пароль rootecho $rootpassword1 | passwd --stdin root#Задаем FQDN ESXi хостаesxcli system hostname set --fqdn=$fqdn1#Задаем настройки IPesxcli network ip interface ipv4 set -i vmk0 -I $ipaddr1 -N $netmask1 -g $defaultgateway1 -t static#Очищаем список DNS серверовesxcli network ip dns server remove -a#Добавляем DNS серверesxcli network ip dns server add --server=$dnsserver1#Перезапускаем сетевой интерфейс для применяния настроекesxcli network ip interface set -e false -i vmk0esxcli network ip interface set -e true -i vmk0esxcfg-init --set-boot-progress-text "OVF customization applied"elseesxcfg-init --set-boot-progress-text "OVF customization disabled."firm -f /tmp/ovf.xmlexit 0

Сохраним файл и выключим хост ESXi из меню выключения.

Важно: для каждого ESXi хоста применятся своя версия скрипта.

Это связано с тем, что в ovf.xml передаются все параметры Guest Properties каждой VM в vApp.

Для ESXi02 в скрипте нужно у всех переменных заменить число в конце переменной на 2.

$rootpassword1 заменить на $rootpassword2

$ipaddr1 заменить на $ipaddr2

и т.д.

#!/bin/sh#Customization script for ESXi02getprops_from_ovfxml() {/bin/python - <<EOSfrom xml.dom.minidom import parseStringovfEnv = open("$1", "r").read()dom = parseString(ovfEnv)section = dom.getElementsByTagName("PropertySection")[0]for property in section.getElementsByTagName("Property"):key = property.getAttribute("oe:key").replace('.','_')value = property.getAttribute("oe:value")print ("{0}={1}".format(key,value))dom.unlink()EOS}#С помощью VMware Tools получаем ovf.xml с параметрами, переданными через Guest Properties/sbin/vmtoolsd --cmd='info-get guestinfo.ovfEnv' >/tmp/ovf.xml 2>/dev/nulleval `getprops_from_ovfxml /tmp/ovf.xml`#Проверяем, что в Guest Properties включена кастомизацияif [ $enablecustomization2 = "enabled" ] ;thenesxcfg-init --set-boot-progress-text "Applying OVF customization..."#Изменяем пароль rootecho $rootpassword2 | passwd --stdin root#Задаем FQDN ESXi хостаesxcli system hostname set --fqdn=$fqdn2#Задаем настройки IPesxcli network ip interface ipv4 set -i vmk0 -I $ipaddr2 -N $netmask2 -g $defaultgateway2 -t static#Очищаем список DNS серверовesxcli network ip dns server remove -a#Добавляем DNS серверesxcli network ip dns server add --server=$dnsserver2#Перезапускаем сетевой интерфейс для применяния настроекesxcli network ip interface set -e false -i vmk0esxcli network ip interface set -e true -i vmk0esxcfg-init --set-boot-progress-text "OVF customization applied"elseesxcfg-init --set-boot-progress-text "OVF customization disabled."firm -f /tmp/ovf.xmlexit 0

#!/bin/sh#Customization script for ESXi03getprops_from_ovfxml() {/bin/python - <<EOSfrom xml.dom.minidom import parseStringovfEnv = open("$1", "r").read()dom = parseString(ovfEnv)section = dom.getElementsByTagName("PropertySection")[0]for property in section.getElementsByTagName("Property"):key = property.getAttribute("oe:key").replace('.','_')value = property.getAttribute("oe:value")print ("{0}={1}".format(key,value))dom.unlink()EOS}#С помощью VMware Tools получаем ovf.xml с параметрами, переданными через Guest Properties/sbin/vmtoolsd --cmd='info-get guestinfo.ovfEnv' >/tmp/ovf.xml 2>/dev/nulleval `getprops_from_ovfxml /tmp/ovf.xml`#Проверяем, что в Guest Properties включена кастомизацияif [ $enablecustomization3 = "enabled" ] ;thenesxcfg-init --set-boot-progress-text "Applying OVF customization..."#Изменяем пароль rootecho $rootpassword3 | passwd --stdin root#Задаем FQDN ESXi хостаesxcli system hostname set --fqdn=$fqdn3#Задаем настройки IPesxcli network ip interface ipv4 set -i vmk0 -I $ipaddr3 -N $netmask3 -g $defaultgateway3 -t static#Очищаем список DNS серверовesxcli network ip dns server remove -a#Добавляем DNS серверesxcli network ip dns server add --server=$dnsserver3#Перезапускаем сетевой интерфейс для применяния настроекesxcli network ip interface set -e false -i vmk0esxcli network ip interface set -e true -i vmk0esxcfg-init --set-boot-progress-text "OVF customization applied"elseesxcfg-init --set-boot-progress-text "OVF customization disabled."firm -f /tmp/ovf.xmlexit 0

После того, как мы добавили скрипты на каждый ESXi хост, через vCenter кликаем на VM -> Configure -> vApp Options -> Edit

Отмечаем пункт Enable vApp options, а на вкладке OVF Details отмечаем пункт VMware Tools. Это нужно для того, чтобы VMware Tools передали ovf.xml внутрь гостевой ОС ESXi

Переходим VM -> Configure -> vApp Options, пролистываем вниз и нажимаем ADD.

Для ESXi01 нужно добавить следующие Properties:

1. enablecustomization1;

2. rootpassword1;

3. fqdn1;

4. ipaddr1;

5. netmask1;

6. defaultgateway1;

7. dnsserver1.

В поле Category указываем название подраздела, в поле Label отображамое имя параметра, а в поле Key ID имя переменной, которую обрабатывает скрипт кастомизации.

Эти параметры можно будет задать в интерфейсе VMware Cloud Director в процессе развёртывания шаблона. Скриншот для наглядности ниже.

Нажимаем ADD и добавляем Properties.

На вкладке Type мы можем выбрать тип параметра, в нашем случае все параметры строковые (String), и выбрать значение по умолчанию (Default value). Это значение будет автоматически подставлено при развёртывании шаблона.

Создаём property для каждого параметра на каждом ESXi хосте.

Корректно заполненные Properties должны выглядеть, как на скриншотах ниже.

4.4. Установка vCenter Server Appliance в vApp

Добавим OVA с vCenter Server Appliance vApp. Конфигурировать и запускать не будем.

Выбираем OVA шаблон vCenter

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

Затем необходимо установить Windows Server 2019 и Ubuntu 18.04 LTS. Это можно сделать, используя ISO-образы, но я пойду более простым путём и разверну их из OVA шаблонов, предварительно скачанных из публичных каталогов VMware Cloud Director (vcd.cloud4y.ru).

4.5. Установка Windows Server 2019 в vApp

Разворачиваем Windows Server из OVA шаблона. Запускаем VM.

Включаем удалённое управление по RDP.

Устанавливаем роль DNS сервера.

Создаём Forward Lookup Zone для domain.local.

Создаём Reverse Lookup Zone для 2.168.192.in-addr.arpa.

Выключаем VM.

4.6. Установка Ubuntu 18.04 LTS в vApp

Концепция следующая:

При развёртывании шаблона в VMware Cloud Director подключаем к VM с Ubuntu 18.04 LTS дополнительный диск, форматируем его в ext4 и расшариваем в нашей подсети средствами NFS.

Настраиваем сеть. Устанавливаем обновления: apt install update && apt install upgrade -y

Устанавливаем NFS сервер: apt install nfs-kernel-server nfs-common -y

Внесём закомментированные строки, которые будет достаточно раскомментировать в случае развёртывания в стандартной конфигурации.

Редактируем /etc/fstab

Редактируем /etc/exports

Выключаем все запущенные VM в vApp.

4.7. Удаление ISO приводов и сетевых адаптеров

Переходим в настройки каждой VM и удаляем все CD-приводы и сетевые адаптеры каждой VM в vApp. CD-приводы нам более не требуются. Сетевые адаптеры удаляем во избежание конфликтов при развёртывании шаблона.

5. Выгрузка vApp шаблона из Working Environment

Выгрузка шаблона из vCenter.

Теперь мы можем выгрузить шаблон.

По окончанию скачивания получаем набор файлов, готовых к загрузке в VMware Cloud Director. Общий размер 11,5 ГБ, но в VMware Cloud Director потребуется около 350ГБ, т.к. у нас используются Thin (тонкие) диски, а VMware Cloud Director рассчитывает размер не по текущему размеру диска, а по максимальному (до которого диски могут быть расширены).

6. Загрузка vApp в VMware Cloud Director

Переходим в vcd.cloud4y.ru и загружаем vApp из OVF.

Нажимаем Browse и выбираем все файлы, которые мы экспортировали из vCenter.

На последующих шагах принимаем EULA и не вносим изменений в параметры развёртывания. Нажимаем Next-> Next -> -> Finish.

Дожидаемся окончания загрузки. Теперь мы можем сохранить готовый vApp в каталог.

Надеемся, что наш туториал по подготовке шаблона vApp тестовой среды VMware vCenter + ESXi в VMware Cloud Director будет вам полезен при работе с вложенной виртуализацией и подготовке среды для неё. Да, в первую очередь информация будет полезна инженерам облачного провайдера. Но для понимания принципов работы облачной инфраструктуры статью можно прочитать и другим техническим специалистам.

Спасибо за внимание!

Что ещё интересного есть в блогеCloud4Y

Пароль как крестраж: ещё один способ защитить свои учётные данные

Тим Бернерс-Ли предлагает хранить персональные данные в подах

Виртуальные машины и тест Гилева

Создание группы доступности AlwaysON на основе кластера Failover

Как настроить SSH-Jump Server

Подписывайтесь на нашTelegram-канал, чтобы не пропустить очередную статью. Пишем не чаще двух раз в неделю и только по делу.

Хабр, привет.

Меня зовут Аркадий и я сетевой инженер в одном из сервис провайдеров. Кому интересны основные отличия VXLAN от Geneve добро пожаловать под кат. Избегая выстрела в ногу, хочу отметить, что основа статьи это выжимки из RFC и открытой информации WMware.

В NSX-T VMware уходит от Overlay на базе VXLAN в пользу Geneve. Внедрение Geneve лоббируется помимо VMWare такими компаниями как : Intel, Microsoft, Red Hat. Маркетинг называет следующую причину к Geneve : "Geneve сочетает в себе лучшее от протоколов VXLAN (Virtual Extensible LAN), NVGRE(Network Virtualization using Generic Routing Encapsulation), and STT(Stateless Transport Tunneling)." Разберем отличия нового Overlay протокола и почему ему отдано предпочтение ведущими вендорами виртуализации.

Теперь по порядку:

Geneve - туннельный протокол работающий поверх UDP (port number) для построения туннелей между NVEs (Network Virtualization Edge) через IP underlay. Описан в RFC8926, который в свою очередь заменил предшествующий драфт draft-gross-geneve 2020-11-06.

Протокол разрабатывался рабочей группой IETF с целью унификации и агрегации преимуществ протоколов VXLAN, NVGRE и STT. Недостатками которых являлись гибкость и ограниченность масштабирования в условиях стремительного развития виртуализации и сервисов на базе глобальных облачных провайдеров.

Основной задачей технологии (протокола) является виртуализация L2 домена работающего поверх базовой IP сети. Широко применяется в облачных средах, в связи с ограничениями по размеру поля VLAN Tag 802.1q в 2 ^ 12 = 4094.

Geneve

Минимальный размер заголовка Geneve составляет 8 байт.

Ver (2 bits) Версия протокола. Текущее значение 0.

Opt Len (6 bits) указание размера поля Variable Length Options. Минимальный размер заголовка + значение Opt Len = полный размер заголовка.

O (1bit) Control packet. Интерпретируется TEPs (tunnel end points). Может использоваться для передачи пакета на обработку выше по стеку.

C (1bit) Critical options present. Установленный бит указывает на необходимость парсинга опций на TEPах. На TEPах поддерживающих парсинг опций пакет должен быть отброшен.

Rsvd.(6 bits) Reserved. Значение поля должно быть = 0 при передаче пакета и игнорируемо на конечных хостах.

Protocol type (16 bits) - 0x6558 Transparent Ethernet Bridging.

VNI (24 bits) Virtual Network Identifier уникальный идентификатор сегмента виртуальной сети. Идентифицирует L2 домен которому принадлежит оригинальный Ethernet фрейм. NSX-T использует диапазон VNI от 5000 до 16777216.

Reserved (8 bits). Значение поля должно быть = 0 при передаче пакета и игнорируемо на конечных хостах.

За базовым заголовком Geneve следует поле опций в TLV формате. Каждая опция состоит из заголовка в 4 байта и данных интерпретируемых в соответствии с полем Type опции. В базовом заголовке предусмотрено поле для идентификации типа опции по организации, технологии, или вендору. Определенный блок IANA зарегистрировала для тестов и оптимизации протокола. Поле опций в заголовке Geneve по тексту RFC в большей степени предусмотрено для масштабирования протокола и возможностей оптимизации протокола разработчиками. В поле тип определено место контрольного бита (C) Critical являющегося глобальным по отношению ко всем TEPs. При обработке TEP пакета при выставленном бите C и не определенным типом опции пакет должен быть отброшен.

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

В сравнении с VXLAN (RFC7348)

VXLAN Flags (8 bits) Набор флагов, в котором I должен быть выставлен в 1 для валидного VNI, R зарезервированные флаги выставленные в 0 при передаче и игнорируемы на приеме

Reserved (24 bits) - Зарезервированные флаги выставленные в 0 при передаче и игнорируемы на приеме

VNI (24 bits) - уникальный идентификатор сегмента виртуальной сети. Идентифицирует L2 домен. Размер поля такой же как у Geneve (порядка 16М номеров).

Reserved (8 bits) - Зарезервированные флаги выставленные в 0 при передаче и игнорируемы на приеме.

Ссылка на vxlan.pcap

Summary по заголовкам пакетов VXLAN и GENEVE:

Одинаковый минимальный размер заголовка 8 байт с возможность расширения Geneve за счет поля опций разной длины. Geneve обладает следующими преимуществами:

• Поддерживает проприетарные* значения полей type, length, value;

• Обладает гибкостью в отношении включения дополнительных метаданных в заголовок;

* ИМХО это кажется основной причиной описания нового стандарта и активного его внедения ведущими вендорами, а не маркетинговый булщит на тему сочетания в себе преимуществ предшественников.

Целиком пакет Geneve over IPv4 выглядит так:

Ссылка на Geneve.pcap

Требования к IP Underlay сетевой инфраструктуры следующие:

• IP связность между TEP

• Отсутствие на пути трафика блокировок UDP6081 Geneve или UDP4789 VXLAN

• Минимальный MTU 1600 байт

Итого

Существенных различий между VXLAN и Geneve на уровне заголовков нет, равно как и на этапе инкапсуляции пакета.

Получилось достаточно кратко. В будущем планирую рассмотреть процесс построения таблиц соответствия (которых три) и этапы передачи Geneve пакета между TEP примере NSX-T.

В РФ ведётся широкое внедрение цифрового строительства и использование цифровых моделей здания (BIM building information modelling) на законодательном уровне. Например, с 18 марта 2021г. вступило в действие Постановление Правительства РФ от 05.03.2021 331 "Об установлении случая, при котором застройщиком, техническим заказчиком, лицом, обеспечивающим или осуществляющим подготовку обоснования инвестиций, и (или) лицом, ответственным за эксплуатацию объекта капитального строительства, обеспечиваются формирование и ведение информационной модели объекта капитального строительства". Выбор технической базы для внедрения новой технологии должен быть оправдан технико-экономическим обоснованием. Подобными исследованиями занимаются зарубежные интеграторы. Данная заметка является вольным переводом исследования от независимого системного архитектора Томаса Поппельгаарда.

В настоящее время BIM-инженеры прикованы к столу. В теории, преимущества замены физических рабочих станций на удаленные налицо. Во-первых, инженеры перестают быть привязанными к физическому рабочему месту. Во-вторых, можно присоединить больше устройств к центральной сети. В-третьих, со стороны локальной сети компании обеспечивается большая централизация вычислений; большие возможности масштабировать телекоммуникационную сеть для графических задач; и проще обеспечить защиту информации. В-четвёртых, решается вопрос организации общего доступа к файлам для рабочей группы. Организация удалённой работы осложняется тем, что со стороны системных администраторов затруднительно масштабировать серверную платформу. Объём данных растёт; они постоянно меняются; и много ресурсов сети занимает синхронизация между сервером и пользователями.

Новые предложения от компании HPE имеют расширенные возможности графического процессора с HPE Proliant m750 и предоставляют выделенный графический процессор от NVIDIA, адаптированный для видеокарт NVIDIA P1000 или NVIDIA T4. Это решение разработано для удовлетворения требований опытных дизайнеров, архитекторов и 3D-дженералистов.

Для организации удалённой работы с высокопроизводительными графическими приложениями HPE имеет 3 аппаратных решения в различных исполнениях по форм-фактору:

• HP Moonshot 1500;

• HPE Edgeline EL4000;

• HPE Edgeline EL8000 / EL8000t.

VMware уже поддерживает установку на серверах без предустановленной операционной системы (bare-metal). Применительно к BIM, данный функционал требует внимательного рассмотрения. 4 недели назад HPEобъявило об официальной поддержке выпускаемого ПО VMware Horizon на bare-metal в HPE Moonshot.

Архитектура HPE Edgeline и VMware Horizon 8

HPE Edgeline и VMware Horizon показывают на рисунке ниже, что вы можете использовать VMware Horizon cloud, но он также полностью поддерживается инфраструктурой On-Premise VMware Horizon, если у вас есть для этого требования. Вы можете использовать тонкий клиент от HP 740, который является лучшим аппаратным тонким клиентом на рынке, который также может декодировать несколько мониторов 4K без каких-либо неудобств для пользователя. Самое замечательное в нижеприведенной архитектуре заключается в том, что вы можете иметь 4 физических рабочих станции в 1U, установленных в вашем центре обработки данных или ином расположении, без ущерба для пользовательской виртуализации. Сила bare-metal в том, что вы выжать максимум от возможностей оборудования. Функциональная схема такой системы показана ниже.

В зависимости от ваших требований HP предлагает очень гибкое решение на новых платформах. Рассмотрим каждую новинку по отдельности.

Коротко о HPE Proliant m750

В модели HPE m750 установлен 8-ядерный процессор AMD16-core с технологией Hyper-threading, что вдвое больше по сравнению с оборудованием, выпущенными за последние 7 лет. Это пригодится пользователям, которым требуется многопоточность, и тем, кто работает с HCI или виртуализацией. Платы также могут быть сконфигурированы с NVMe емкостью до 16 ТБ, что наводит на мысли о невероятно малом форм-факторе и о том, как мало энергии он потребляет (максимум 90 Вт). HP m750 также работает под управлением любой операционной системы и гипервизора. Также он использует iLO 5, используя который системный администратор имеет большее удобство в управлении сервером.

Коротко о NVIDIA T4

NVIDIA T4 - это однослотовый графический процессор от NVIDIA, использующий архитектуру Тьюринга от NVIDIA и являющийся частью серии Quadra. Этот графический процессор обладает возможностями RTX и адаптирован для трассировки лучей в реальном времени. Графический процессор имеет 16 ГБ выделенного кадрового буфера GDDR6, который требуется для высокопроизводительных САПР-приложений. Драйвера Nvidia Т4 могут быть использованы и в bare-metal, и на виртуальных машинах. В сочетании с NVIDIA vGPU буфер кадров может быть разделён на сегменты от 2 ГБ до 16 ГБ. Это означает, что вы можете запустить до 8 виртуальных пользователей. Идея в том, чтобы дать пользователю выделенную мощность m750 (5 ГГц CPU 8c/16c, до 16 ТБ NVMe, объём памяти 64 ГБ) и заставить его перейти в удалённый центр обработки данных. NVIDIA T4 требует лицензий vGPU как в установке bare-metal, так и в виртуализированной среде.

Тестирование HPE Edgeline m750 + GPU от Nvidia с VMware

Для тестирования были выбраны следующее оборудование: HPE m750 с процессором Intel Xeon и встроенным графическим процессором Intel P630, NVIDIA P1000. В качестве программного обеспечения, устанавливаемого на серверную платформу, использовались Windows 10 1909 и VMware Horizon 8.

Суммарный перечень программ, используемых в тестировании на быстродействие удалённого рабочего места:

• Adobe Photoshop CC 2020 с дополнением Puget System;

• Autodesk Inventor Professional 2020 с дополнением Inventor;

• Furmark (OpenGL);

• SPECworkstation 3;

• SPECviewPerf3;

• Basemark GPU;

• Unigine Superposition.

Итог тестирования

Гибкость развертывания bare-metal (m750/P1000) или сборки с виртуализацией (m750/T4) измерялась в зависимости от требований приложения и по показателю изменения соотношения вычислений к загрузке графического процессора. Виртуализация на EL4000/m750/T4 оказалась экономически эффективным методом централизации и предоставления удаленного доступа для пользователей САПР малого и среднего бизнеса. Вы можете использовать либо 1-2 блока EL4000 настенного монтажа для небольшого числа пользователей (до 32), либо укладывать до 20 блоков в стойку для смешанного развертывания до 300 пользователей. Как оборудование будет располагаться в 19" стойке отражено на картинке ниже.

Для программ Autodesk Revit 2020, Autodesk Navisworks 2020, Autodesk Inventor 2020, Autodesk 3DSMax 2020 HP T740 обеспечивает лучшее отображение на 2-х 4K-мониторах при работе пользователя VMware Blast Extreme для m750 с NVIDIA P1000. У пользователя есть возможность работать с HP Thinpro с помощью клиента VMware Horizon. NVIDIA P1000 обеспечивает отличную работу с BIM-образцами средней детализации. Если клиентам требуются более крупные наборы данных, то NVIDIA T4 является предпочтительным выбором для использования с HPE m750. NVIDIA vGPU является предпочтительным выбором, если клиенты хотят масштабировать свой центр обработки данных и достичь высокой плотности пользователей виртуальных машин с максимальной производительностью.

В процессе тестирования наблюдалось изменение полосы пропускания с пиками до 30 Мбит/с на пользователя при изменении масштаба или вращении больших визуальных объектов в САПР-приложениях. Протокол VMware blast адаптируется и оптимизируется из коробки в последней версии с 2D/3D приложениями и не требует настройки оптимизации. При переходе от dual HD к dual 4K следует учитывать, что пропускная способность будет использоваться в 4 раза больше.

Рекомендации

Решение 1 предназначено для клиентов, которые хотели бы использовать процессор 5 ГГц для приложений с высокими требованиями производительности и для работы с 2D-графикой на отдельном процессоре. Например, AutoCAD, 4K video, Office365. Предлагаемый сервер вместе с VMware Horizon обеспечивает отличную производительность даже на мониторах 4K, где VMware обеспечивает аппаратную возможность декодирования как с процессором, так и с графическим процессором.

Решение 2 предназначено для клиентов, использующих базовые возможности САПР таких как AutoCAD, Revit, Navisworks, Inventor. Видеокарта NVIDIA P1000 обеспечивает отличную производительность с VMware Horizon и декодированием GPU из коробки на мониторах 4K.

Решение 3 предназначено для клиентов, которые использующих расширенные возможности работы с AutoCAD, Revit, Navisworks, Inventor. Виртуализация m750, сочетание технологии NVIDIA T4 с технологией vGPU, работающей на VMware vSphere - отличное решение, масштабируемое от 4 до 32 пользователей. Клиенты получают лучшую производительность за эти деньги, так как они могут эффективно использовать аппаратное обеспечение. Трассировка лучей в реальном времени также поддерживается NVIDIA vGPU но для более высоких рабочих нагрузок рекомендуется использовать большие фреймбуферы.

Решение 4 предназначено для клиентов, использующих высокопроизводительные приложения, такие как Autodesk VRED, Maya, Arnold, 3DSMax или Dassault Catia. Решение полностью поддерживает трассировку лучей в реальном времени, поскольку графический процессор NVIDIA T4 способен обеспечить эти возможности. Это решение также предпочтительно, если клиенты хотят использовать VR-решения, такие как NVIDIA CloudXR, где они могут объединить его с VMware Horizon.

Внимание, вопрос: кто стоял у истоков виртуализации? При всей любви к продуктам этой компании, ответ VMware будет неверен. Пионерами на этом рынке были General Electric, Bell Labs и IBM.

Сотворение виртуальной машины

Уже в начале шестидесятых портфолио IBM насчитывало десятки различных систем. Каждое новое поколение разительно отличалось от предыдущего. Покупатели рвали на себе волосы в тщетных попытках поспеть за всеми инновациями и требованиями нового железа. Кроме того, в те годы еще была актуальна парадигма один компьютер за один присест выполняет только одну задачу. Вам нужно больше? Будьте добры прибегнуть к пакетной обработке (batch processing), когда одно задание выполняется на ЭВМ вслед за другим без вмешательства оператора. Неудобно, правда? Но специалисты IBM не считали это проблемой. Большая часть пользователей их машин принадлежала к научному сообществу. Им вполне хватало.

Но разнообразие систем понемногу начало досаждать IBM. Компания приняла решение заместить свой технологический зоопарк новым мейнфреймом S/360, который ко всему прочему обладал бы обратной совместимостью. Предполагалось, что компьютер будет однопользовательским и сможет работать с пакетами задач.

К первому июля 1963 года эта концепция развалилась. MIT анонсировал Project MAC Mathematics and Computation, а не то, о чем вы могли бы подумать. Более поздняя расшифровка этого названия звучит как Multiple Access Computer. Финансировался проект щедрым грантом DARPA объемом в $2 млн средства были выделены в том числе на изучение особенностей и перспектив компьютеростроения в основном, в области разработки операционных систем, искусственного интеллекта и теории вычислений. А новый грант это новые задачи. И, соответственно, новый компьютер, который сможет с ними справиться. MIT требовалась не простая, а многопользовательская машина. Первое, о чем подумали инженеры почему бы не заказать готовый компьютер у GE или IBM?. Однако IBM на тот момент пребывала в уверенности, что спроса на машины с разделением времени практически нет. А модифицированную под все хотелки версию стокового IBM-компьютера в MIT покупать не хотели. GE, напротив, с удовольствием приняла предложение MIT и решилась взяться за разработку многопользовательской машины.

И тут оказалось, что спрос на такие машины на рынке есть. Притом весьма солидный даже в Bell Labs заинтересовались в их приобретении. Тревожный звоночек.

В ответ на предложения от MIT и Bell Labs в IBM была срочно разработана и выпущена CP-40. Это первая операционная система, которая реализовывала полную виртуализацию. CP-40 была предназначена специально для IBM S/360 model 40 и поддерживала до 14 виртуальных машин c 256 Кб виртуальной памяти одновременно.

Параллельно с CP-40 была разработана программа CMS. Она обеспечивала среду для запуска приложений и взаимодействия с пользователями. CMS была крохотной интерактивной ОС для одного пользователя. Вся магия виртуализации обеспечивалась именно CP. Суть в том, что CP запускалась на мейнфрейме и создавала N-ное количество виртуальных машин под управлением CMS. Первый релиз CP/CMS состоялся в 1968-ом году, а к 1972-му на рынок была выпущена ее стабильная версия.

Традиционно компьютеры с таймшерингом поровну делили между несколькими пользователями процессорное время, память и прочие ресурсы. Характерный пример ОС MultiCS, разработанная в MIT для Project MAC. Позднее она была передана в Bell Labs, где впоследствии эволюционировала в Unix.

Подход CP был существенно проще и удобнее для пользователя: каждый, кто садился за компьютер, получал свою собственную машину. Выгода заключалась в том, что виртуальные машины имели доступ сразу ко всем ресурсам мейнфрейма, а не запирались в урезанном выделенном сегменте. Кроме того, это было более безопасно и надежно: никто не мог залезть в чужую ОС или уронить сразу весь мейнфрейм.

Вслед за CP-40 была разработана ОС CP-67. Именно ее можно назвать первым промышленным гипервизором. Позднее CP-67 эволюционировала в VM/370 для мейнфрейма S/370.

Переносимость программного обеспечения

Чуть выше мы упомянули Unix. Несмотря на то, что эта ОС не умеет запускать гостевые операционные системы, она подойдет для иллюстрации другого свойства ПО.

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

В зависимости от конфигурации системы пользователь может установить собственный набор дополнительного ПО и управлять политиками безопасности. Но не только этим славна Unix де-факто, это первая операционная система, открывшая дорогу к виртуализации приложений.

Все ее предшественники писались на голом языке ассемблера, что намертво привязывало их к конкретному компьютерному железу. В то же время C, на котором была написана Unix, позволял портировать ее на любой компьютер с куда меньшими усилиями. Достаточно было переписать специфичные участки кода и перекомпилировать ОС для новой платформы. Переносимость сделала Unix самой популярной системой своего времени.

Виртуализация приложений

Любой искушенный пользователь Unix, владеющий компиляторами C, мог без труда запустить любую программу на любом компьютере. Удобно? Почти. Осталось найти способ переносить приложения между компьютерами, минуя процесс компиляции. То есть виртуализировать их.

В 1990 году Sun Microsystems запустила проект Stealth. Он был инициирован инженерами компании, которым не нравился подход Sun к использованию API C и C++. Они были уверены в том, что есть лучший способ писать и запускать приложения. Проект несколько раз переименовывали среди версий были даже экзотичные Oak и Web Runner. Как вы уже наверняка догадались, в 1995 году проект достиг релиза под окончательным именем Java.

Планировалось, что наибольшее применение Java найдет во всемирной паутине. Интернет это колоссальная сеть, состоящая из компьютеров, работающих под разными операционными системами. Платформа, которая позволит запускать одни и те же приложения на всех этих машинах без необходимости переписывать и перекомпилировать их, была обречена на успех. В 1996 году в свет вышел Java Development Kit (JDK).

Java был уникален в своем роде. Можно было запустить написанную на нем программу на любом компьютере с установленной бесплатной Java Run-Time Environment (JRE).

Говоря упрощенно, Java работает так: сначала написанная программа компилируется в байт-код Java. Это своеобразный язык-посредник, с которым умеет работать JRE. Непосредственно в момент запуска программы JRE компилирует программу из байт-кода для целевого железа. Программисту не надо заботиться о том, для какого железа и какой ОС он пишет код, а пользователю не приходится заниматься компиляцией.

JRE включает в себя массу компонентов, наиболее интересным из которых является Java Virtual Machine. Любое приложение запускается именно в ней. Можно представить себе JVM как очень маленькую ОС, созданную для того, чтобы запускать Java-приложения. Заботы о портировании JVM для всех мыслимых устройств Sun/Oracle берет на себя. Тем не менее, этот подход имеет известные ограничения.

Широкое распространение аппаратной виртуализации

Как было сказано выше, IBM первой применила концепцию виртуальных машин в коммерческой среде. Виртуальные машины, подобные тем, что запускались на мейнфреймах IBM, до сих пор используются, хотя большинство компаний отказались от мейнфреймов.

Еще в январе 1987 года Insignia Solutions продемонстрировала программный эмулятор под названием SoftPC. Он позволял запускать приложения DOS на рабочих станциях под управлением Unix. Это был невероятный цифровой подвиг. В то время ПК, способный запустить MS-DOS, стоил порядка $1500, а использование SoftPC обходилось всего в $500.

К 1989 году Insignia Solutions выпустила версию SoftPC для Mac. В этой версии была добавлена возможность запускать приложения Windows. К 1994 году Insignia Solutions начала продавать свое программное обеспечение с разными предустановленными операционными системами в том числе с SoftWindows и SoftOS/2.

Успех SoftPC вдохновил и других игроков. В 1997 году Apple создала программу под названием Virtual PC и начала распространять ее через компанию Connectix. Virtual PC, как и SoftPC, позволял пользователям запускать копию Windows на Mac, это позволило обойти проблему несовместимости программного обеспечения. А в 1998 году была основана всемирно известная компания VMware. Год спустя на рынок вышла первая версия VMware Workstation. Сначала она была доступна только в Windows, но позже добавилась поддержка других операционных систем.

VMware достойна упоминания хотя бы потому, что на данный момент это безусловный лидер рынка виртуализации. В 2001 году VMware выпустила два новых продукта для корпоративного сегмента: ESX Server и GSX Server. GSX Server позволял пользователям запускать виртуальные машины поверх существующей операционной системы, например Microsoft Windows. Это так называемый гипервизор 2-го типа. ESX Server, гипервизор 1-го типа, не требует наличия ОС-хоста.

Гипервизоры 1-го типа намного более эффективны, поскольку для их работы не требуется выделять ресурсы на запуск основной системы. Кроме того, они традиционно более гибки в настройке.

После выпуска ESX Server в 2001 году в корпоративном сегменте наметился экспоненциальный рост интереса к виртуализации. VMware добавила много дополнительных продуктов для улучшения функционала ESX Server.

Появились и другие поставщики ПО для виртуализации. В 2003 году Microsoft приобрела Connectix, и Virtual PC была переиздана. Сначала под брендом Microsoft Virtual PC 2004, затем Microsoft Virtual Server 2005.

В 2007 на рынке виртуализации появился еще один игрок Citrix Inc. Компания приобрела XenSource, платформу виртуализации с открытым исходным кодом, созданную в 2003 году, и вскоре после этого переименовала продукт в XenServer.

Публикация приложений

Во времена UNIX доступ к опубликованным приложениям можно было получить через Telnet, а затем SSH.

Windows и OS/2 не давали удаленного доступа к приложениям без использования сторонних инструментов. А существовавшее специализированное ПО было доступно только одному пользователю за раз.

Кому-то в IBM пришла в голову идея создать многопользовательский интерфейс для OS/2, однако боссам компании идея не пришлась по вкусу. В 1989 году Эд Якобуччи ушел из IBM и основал собственную компанию под названием Citrus. Вскоре компания была переименована в Citrix, комбинацию Citrus и Unix.

Citrix получила лицензию на исходный код OS/2 и приступила к созданию программного расширения для нее. Два года спустя OS/2 таки получила многопользовательский интерфейс MULTIUSER.

В 1991 году Microsoft объявила об окончании поддержки OS/2, и Citrix пришлось свернуть проект. Однако полученный опыт позволил переориентироваться на создание подобного ПО, но уже для Windows.

В 1993 году Citrix приобрела Netware Access Server у Novell. В 1995 году этот продукт начал продаваться под именем WinFrame. WinFrame представляла из себя Windows NT 3.5 с возможностями удаленного доступа. Сразу несколько пользователей могли одновременно подключиться к ней для удаленного запуска приложений.

Во время разработки WinFrame для Windows NT 4.0 Microsoft отказала Citrix в лицензии, и продукт по соглашению сторон был интегрирован в Windows NT 4.0 в качестве набора служб терминалов. Citrix согласилась не создавать конкурирующий продукт, но получила возможность расширить функциональные возможности служб терминалов.

Виртуальные рабочие столы

Виртуальные рабочие столы в их современном понимании это весьма молодая тема. В чем-то их концепция похожа на то, что IBM предложила в далеких 1960-х. Каждый пользователь получает собственную выделенную ОС и может делать в ней всё, что ему заблагорассудится, не подвергая опасности других пользователей в системе.

Переход от виртуальных рабочих столов на мэйнфреймах к виртуальным рабочим столам в том виде, в каком мы их знаем сегодня, на самом деле произошел только в 2007 году, когда VMware представила свой продукт для VDI. В принципе, сотрудники компаний и ранее могли пользоваться виртуальными рабочими столами в качестве основного ПК, но это было сопряжено с массой административных сложностей. А появление Virtual Machine Manager и аналогичных продуктов дало мощный старт целому направлению в области виртуализации.

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

Этой небольшой статьей-заметкой мы хотели бы завершить серию публикаций, посвященных истории виртуализации в Enterprise-сегменте рынка. Сегодня поговорим о VMware, компании, которая на сегодняшний день является фактическим законодателем в мире виртуализации. Давайте посмотрим, как выглядели одни из самых ранних продуктов VMware: GSX и ESX.

VMware была основана в 1998 году. Её первым коммерчески успешным продуктом считается VMware Workstation, выпущенный в 1999 году и предназначенный для работы на клиентском железе.

Для серверных рабочих нагрузок в следующие 2 года был с нуля разработан продукт VMware GSX Server. Его название это сокращение от более длинного рабочего имени Ground Storm X. Первая коммерческая версия 1.0 датируется 2001-м годом. Устанавливалась она поверх Windows Server или SUSE Linux, что характеризует ее как гипервизор 2-го типа.

Усовершенствованная версия GSX Server 2.0 увидела свет через год, летом 2002-го. Под своим оригинальным именем продукт просуществовал вплоть до декабря 2005-го, когда была выпущена последняя коммерческая версия 3.2.1.

Гипервизор завоевал популярность благодаря широкому списку поддерживаемого оборудования (от сервера до обыкновенного десктопа) и простоте установки и первичной настройки. Кроме того в GSX наличествовали встроенные NAT и DHCP-сервер, что существенно облегчало процесс настройки сети.

Затем GSX Server был переименован в VMware Server и стал распространяться совершенно бесплатно. В списке поддерживаемых гостевых систем появились и 64-битные ОС, а гипервизор получил возможность выделять машинам несколько vCPU. VMware Server появилась 12 июля 2006-го и официально поддерживалась вплоть до 2011-го.

Сладкий плод виртуализации понравился инженерами VMware. Гипервизоры 2-го типа это хорошо, но 1-й тип способен дать гораздо больше возможностей!

Параллельно с GSX Server шла разработка нового гипервизора типа 1. В отличие от предшественника, его уже можно было установить на голое серверное железо без ОС-посредника.

Продукт получил рабочее название VMware Scalable Server. В настоящее время он известен уже под именем ESXi. Ниже приводим скриншот, приблизительно датированный 1999-2000 годом.

Уже совсем скоро, к 2000-му, проект получил новое название: VMware Workgroup Server. А в марте 2001-го компания официально выпустила VMware ESX 1.0 Server. ESX это аббревиатура от Elastic Sky X. Забавно, но придумали его вне стен VMware. Сотрудники компании прекрасно разбирались в компьютерах, но ничего не смыслили в рекламе и маркетинге. Специально нанятое агентство предложила лаконичный вариант Elastic Sky. Инженеры взбунтовались: как это, новый коммерческий продукт, в названии которого нет ни малейшей технарской изюминки?!

И добавили в конце загадочный X. Почему? Вероятно, чтоб никто не догадался!. Да и звучит более круто. Забавно, как точно это имя попало в цель: вряд ли в далеком 2001-м кто-то придумывал его с оглядкой на облачные вычисления.

Впоследствии вокруг нового продукта сформировался целый отдел, самым известным сотрудником которого был Джон Аррасджид, один из авторов и ведущий архитектор vCloud Architecture Toolkit (vCAT).

VMware ESX Server стал первым на рынке гипервизором 1-го типа для Intel x86. В нем были впервые реализованы многие функции, ставшие едва ли не стандартом: живая миграция виртуальных машин, High Availability, автоматический балансировщик нагрузки, инструменты управление питанием и т.п.

В течение нескольких лет ESX и GSX были одновременно доступны широкой аудитории. GSX целился в более приземленную аудиторию: малый бизнес, небольшие государственные учреждения, в то время как ESX стал флагманским продуктом для Enterprise-сектора. Однако по-настоящему серьезно ESX начал использоваться лишь к 2006 году.

Среди прочего ESX имел сервисную консоль. Ее роль выполняла виртуальная машина на Linux, через которую можно было управлять хостом и другими ВМ. Для установки дополнительно программного обеспечения сторонних производителей (например, сервисов резервного копирования) предполагалось использовать программы-агенты.

Еще до того, как ESX начал серьезное распространение в бизнес-среде, началась разработка его преемника, уже без сервисной консоли. К сентябрю 2004-го внутри компании состоялась презентация первой полнофункциональной версии продукта под названием VMvisor (VMware Hypervisor). Через 3 года этот продукт появится на рынке под общеизвестным именем ESXi.

На выставке VMworld 2007 компания представила VMware ESXi версии 3.5. Прошлые версии программы существовали только в недрах VMware и не демонстрировались широкой публике.

ESXi занимает гораздо меньше места, чем ESX, и может быть установлен во флэш-память. Фактически, его уже можно рассматривать как часть сервера на это намекает буква i в его названии. Она означает Integrated, интегрированный.

Вплоть до выхода vSphere 4.1 VMware предлагала клиентам два варианта: VMware ESX с Linux-консолью и ESXi с меню настройки сервера. Поддержка ESX официально завершилась с выпуском vSphere 5.

Программное обеспечение, как и гипервизор, несколько раз меняло названия. Например, VMware VMcenter настолько редко и давно использовалось, что по нему даже толком ничего не гуглится. Разумно предположить, что это одно из внутренних наименований продукта. Оно фигурирует, например, на этом скриншоте:

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

Многие администраторы VMware ESXi сталкивались с такой проблемой, как фиолетовый экран смерти. Самое неприятное в этой проблеме, что у вас возникает недоверие к своей собственной инфраструктуре. В голове постоянно крутятся мысли о том, что такая же проблема может повториться и на другом сервере.

Что такое PSOD?

PSOD расшифровывается, как Purple Screen of Diagnostics, часто называемый Purple Screen of Death от более известного Blue Screen of Death, встречающегося в Microsoft Windows.

Это диагностический экран, отображаемый VMware ESXi, когда ядро обнаруживает фатальную ошибку, при которой оно либо не может безопасно восстановиться, либо не может продолжать работу.

Он показывает состояние памяти во время сбоя, а также дополнительные сведения, которые важны для устранения причины сбоя: версия и сборка ESXi, тип исключения, дамп регистра, обратную трассировку, время безотказной работы сервера, сообщения об ошибках и информацию о дампе ядра. (файл, созданный после ошибки, содержащий дополнительную диагностическую информацию).

Данный экран отображается в консоли сервера. Чтобы увидеть его, вам нужно будет либо находиться в центре обработки данных и подключить монитор, либо подключиться удаленно с помощью внеполосного управления сервером (iLO, iDRAC, IMM и т.д. в зависимости от вашего вендора).

Почему появляется PSOD?

PSOD- этосбой в ядре. Все мы знаем, что ESXi не основан на UNIX, но механика сбоя соответствует определению UNIX. Ядро ESXi (vmkernel) запускает эту меру безопасности в ответ на события или ошибки, которые невозможно исправить, это будет означать, что продолжение работы может создать высокий риск для служб и виртуальных машин. Проще говоря: когда хосты ESXi чувствуют, что они повреждены, они совершают харакири и, истекая пурпурной кровью, пишут предсмертную записку с подробным описанием причин, по которым они это сделали!

Наиболее частые причины PSOD:

1. Аппаратные сбои, в основном связанные с RAM или CPU. Обычно они выдают ошибку MCE или NMI.

MCE исключение проверки компьютера, которое представляет собой механизм в ЦП для обнаружения и сообщения о проблемах с оборудованием. В кодах, отображаемых на фиолетовом экране, есть важные детали для определения основной причины проблемы.

NMI немаскируемое прерывание, то есть аппаратное прерывание, которое не может игнорироваться процессором. Поскольку NMI является очень важным сообщением об отказе HW, ответ по умолчанию, начиная с ESXi 5.0 и более поздних версий, должен запускать PSOD. Более ранние версии просто регистрировали ошибку и продолжали. Как и в случае с MCE, фиолетовый экран, вызванный NMI, предоставляетважные коды, которые имеют решающее значение для устранения неполадок.

2. Программные ошибки

неверное взаимодействие между компонентами ESXi SW (см.KB2105711)

условия гонки (см.KB2136430)

из ресурсов: память, динамическая область памяти, буфер (см.KB2034111,KB2150280)

бесконечный цикл + переполнение стека (см.KB2105522)

неверные или неподдерживаемые параметры конфигурации (см.KB2012125,KB2127997)

3. Некорректно функционирующие драйвера;ошибки в драйверах, которые пытаются получить доступ к некорректному индексу или несуществующему методу (см.KB2146526,KB2148123)

Какое влияние оказывает PSOD?

Когда возникает сбой, хост выходит из строя изавершает работу всех служб, работающих на нем, вместе со всеми размещенными виртуальными машинами. Виртуальные машины отключаются резко ине завершаютсвою работу корректно. Если хост является частью кластера и вы настроили HA, эти виртуальные машины будут запущены на других хостах в кластере. Помимо простоя и недоступности виртуальных машин во время их простоя, грязное завершение может повлиять на некоторые критически важные приложения, такие как серверы баз данных, очереди сообщений или задания резервного копирования.

Кроме того, все другие службы, предоставляемые хостом, будут прекращены, поэтому, если ваш хост является частью кластера VSAN, PSOD также повлияет на vSAN.

Что делать?

1. Проанализируйте сообщение на фиолетовом экране.

Одна из самых важных вещей, которые нужно сделать при появлении фиолетового экрана - это сделать снимок экрана. Если вы подключаетесь к консоли удаленно (IMM, iLO, iDRAC, ), будет легко сделать снимок экрана, если нет такой возможности, хотя сфотографируйте экран на телефон. На этом экране много полезной информации о причине сбоя.

2. Обратитесь в службу поддержки VMware.

Прежде чем приступить к дальнейшему исследованию и устранению неполадок, рекомендуется обратиться в службу поддержки VMware, если у вас есть контракт на поддержку. Параллельно с вашим расследованием они смогут помочь вам в проведении корневого анализа причин (RCA).

3. Перезагрузите затронутый хост ESXi.

Чтобы восстановить сервер, вам необходимо перезагрузить его. Я бы также посоветовал оставить его в режиме обслуживания, пока вы не выполните полный анализ RCA, пока не будет определена и исправлена ошибка. Если вы не можете позволить себе держать его в режиме обслуживания, по крайней мере, точно настройте свои правила DRS, чтобы на нем работали только второстепенные виртуальные машины, чтобы в случае возникновения другого PSOD влияние было минимальным.

4. Получите coredump

После загрузки сервера вы должны собрать дамп ядра -coredump. Coredump, также называемый vmkernel-zdump, представляет собой файл, содержащий журналы с более подробной информацией, чем та, что отображается на фиолетовом экране диагностики, и будет использоваться при дальнейшем устранении неполадок. Даже если причина сбоя может показаться очевидной из сообщения PSOD, которое вы проанализировали на шаге 1, рекомендуется подтвердить ее, просмотрев журналы из coredump.

В зависимости от вашей конфигурации у вас может быть дамп ядра в одной из следующих форм:

а. Во временномразделе

b. В виде файла.dumpв одном из хранилищ данных хоста

c. В виде файла.dumpна vCenter через службу netdump

Coredump становится особенно важным, если конфигурация хоста должна автоматически сбрасываться после PSOD , и в этом случае вы не увидите сообщение на экране. Вы можете скопировать файл дампа с хоста ESXi с помощью SCP, а затем открыть его с помощью текстового редактора (например, Notepad ++). Он будет вмещать содержимое памяти на момент сбоя, и первые его части будут содержать сообщения, которые вы видели на фиолетовом экране. Служба поддержки VMware может запросить весь файл, но у вас лишь будет возможность извлечь только журнал vmkernel, который более нагляден:

5. Расшифруйте ошибку.

Устранение неполадок и анализ причин позволяют почувствовать себя Шерлоком Холмсом. Самый важный симптом, с которого вам следует начать, - это сообщение об ошибке, создаваемое фиолетовым экраном.К счастью, количество выдаваемых сообщений об ошибках ограничено:

Exception Type 0 #DE: Divide Error
Exception Type 1 #DB: Debug Exception
Exception Type 2 NMI: Non-Maskable Interrupt
Exception Type 3 #BP: Breakpoint Exception
Exception Type 4 #OF: Overflow (INTO instruction)
Exception Type 5 #BR: Bounds check (BOUND instruction)
Exception Type 6 #UD: Invalid Opcode
Exception Type 7 #NM: Coprocessor not available
Exception Type 8 #DF: Double Fault
Exception Type 10 #TS: Invalid TSS
Exception Type 11 #NP: Segment Not Present
Exception Type 12 #SS: Stack Segment Fault
Exception Type 13 #GP: General Protection Fault
Exception Type 14 #PF: Page Fault
Exception Type 16 #MF: Coprocessor error
Exception Type 17 #AC: Alignment Check
Exception Type 18 #MC: Machine Check Exception
Exception Type 19 #XF: SIMD Floating-Point Exception
Exception Type 20-31: Reserved
Exception Type 32-255: User-defined (clock scheduler)

Поскольку сбой в ядре обрабатывается процессором, для получения дополнительной информации об этих исключениях см. Руководство разработчика программного обеспечения для архитектур Intel 64 и IA-32, том 1: Базовая архитектура иРуководство разработчика программного обеспечения для архитектур Intel 64 и IA-32, том 3A.

Наиболее распространенные случаи описаны в отдельных статьях базы знаний VMware. Поэтому используйте эту таблицу в качестве индекса для ошибок PSOD:

6. Проверьте журналы

Может случиться так, что причина не очень очевидна при просмотре фиолетового сообщения на экране или журнала дампа ядра, поэтому следующее место, где искать подсказки, - это журналы хоста, особенно во временном интервале, непосредственно предшествующем PSOD.Даже если вы чувствуете, что нашли причину, все же рекомендуется подтвердить ее, просмотрев журналы.

Если вы администрируете корпоративную среду, вероятно, у вас под рукой есть специализированное решение для управленияжурналами(например,VMware Log Insight или SolarWinds LEM), поэтому их будет легко просматривать, но если у вас нет управления журналами, вы можете легкоэкспортировать их.

Наиболее интересные файлы журналов для изучения: