Назад | Перейти на главную страницу

Какой рекомендуемый способ версии VMware Templates?

Предположим, вы работаете в организации с многочисленными центрами обработки данных, каждый из которых имеет собственное частное облако, работающее на VMware vCenter 5.5. Существуют шаблоны VMware для разных операционных систем, включая Windows, Redhat Linux и т. Д.

Предположим, есть два частных облака, C1 и C2. C1 был построен год назад, а C2 совсем недавно. Предположим, он работает под управлением Windows 2012. Базовый шаблон обновлялся несколько раз с момента создания C1. Например, платформа .NET была обновлена ​​с v4.0 до v4.5, а затем до v4.5.1.

Виртуальную машину в C1 необходимо перестроить. Однако программное обеспечение, работающее на этой виртуальной машине, несовместимо с .NET v4.5 или v4.5.1. Итак, единственный шаблон, который у нас есть, несовместим. Мы должны воссоздать шаблон, с небольшой вероятностью, что может быть установлен какой-либо патч ОС и т. Д., Который вызывает проблемы для виртуальной машины.

Так что, похоже, лучше всего использовать шаблоны версий. Какой подход лучше?

Вот что я пробовал:

  1. Создавайте снимки перед обновлением шаблона. Инструменты VMware vSphere по-прежнему считают его одним шаблоном, поэтому создание виртуальной машины из моментального снимка «20131031 02:00» требует немного больше усилий.
  2. Дублируйте шаблон, так что теперь у нас есть «Windows Server 2012 (20131031)», «Windows Server 2012 (20130331)» и «Windows Server 2012 (20140601)». Инструменты хорошо это поддерживают. У нас может быстро возникнуть беспорядок, когда люди понятия не имеют, что установлено на каком шаблоне.
  3. После обновления шаблона экспортируйте его. В инструментах VMware доступен только последний шаблон, но я всегда могу восстановить старую версию шаблона, если возникнет проблема.

Возможно, существует более надежный способ управления версиями шаблонов VMware?

Я думаю, вы пытаетесь решить свою проблему неправильными инструментами. Шаблоны VMware очень похожи на традиционные образы операционных систем. Они существуют для того, чтобы на самом деле делать две вещи: 1) обеспечивать согласованную заведомо работоспособную базу, с которой запускаются все ваши серверы, и 2) уменьшать повторение административных задач, необходимых для перехода с установочного носителя в это заведомо исправное состояние. Вы создаете свой шаблон, чтобы он соответствовал наиболее распространенной конфигурации вашего парка. Если у вас так много разных потребностей, что ваш шаблон «общего знаменателя» настолько невелик, что существует огромный разрыв между шаблоном и желаемым состоянием, вы должны начать выполнять математические вычисления, чтобы определить, стоит ли усилий по поддержке нескольких шаблонов. вы сохранили с точки зрения задач, необходимых для перехода от вашего шаблона «общего знаменателя» к вашему специализированному шаблону. По моему опыту, поддержка нескольких шаблонов или изображений часто требует гораздо больше усилий, чем усилий, необходимых для выполнения конфигурации. Как вы обнаружили, поддержка различных шаблонов представляет собой логарифмическую кривую, а не линейную, особенно в гетерогенной среде. Вот почему создание образов так хорошо работает для настольных компьютеров, но менее полезно для серверов.

Ваше решение заключается в сокращении трудозатрат, необходимых для перехода от вашего шаблона «общего знаменателя» к вашей специализированной желаемой конфигурации. По сути, это управление конфигурацией. В экосистеме Windows вам нужны такие инструменты, как GPO, PowerShell DSC и SCCM. Я менее знаком с корпоративными инструментами в мире Linux, но что-то вроде Puppet или Chef должно работать.

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

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