Планирование зарезервированных экземпляров Azure и групп гибкости

При планировании и разработке стратегии экономии затрат в Microsoft Azure одним из первых пунктов является понимание того, что у вас есть, и ваших вариантов продвижения вперед. Чтобы справиться со сбором информации и обработать цифры, чтобы помочь процессу принятия решений, я создал сценарий и электронную таблицу, которые дадут вам обзор вашей текущей среды. Вы можете разработать свой новый стандарт, чтобы разместить все ваши виртуальные машины в определенных размерах семейства, и вы можете создать план действий для каждой отдельной виртуальной машины. Прежде чем приступить к работе, загрузите оба файла (сценарий и электронную таблицу). Они доступны на моем GitHub, и вы можете найти их, щелкнув здесь (скрипт групп гибкости) и здесь (таблица шаблонов).

Первым шагом (элемент 1) является запуск сценария, который называется и сценарий сгенерирует восемь файлов CSV (элемент 2), которые мы собираемся использовать в качестве источника для загрузки информации в нашу электронную таблицу.

В скрипте есть переменная для определения региона — если вы не в Canada Central, обязательно обновите ее перед запуском. Регион важен для размеров виртуальных машин, которые не доступны в равной степени в разных регионах Azure.

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

Имя таблицы будет соответствовать CSV-файлу, сгенерированному скриптом. Мы можем начать с перечисления всех существующих CSV-файлов, сгенерированных нашим скриптом (пункт 1). В нашем случае мы получим информацию с помощью Get-Content FlexInfo.csv (пункт 2). Затем мы собираемся скопировать действительную информацию (не заголовки) из вывода (элементы 3 и 4).

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

Для информационной таблицы Current-Flexibility Group мы знаем, что нам нужны два столбца недвижимого имущества для операции обмена. Мы можем выбрать ячейку , например, щелкнуть стрелку, указывающую вниз, на кнопке (элемент 1), а затем нажать «Использовать мастер импорта текста…» (элемент 2).

Отобразится новый мастер. Обязательно выберите запятую на . Результатом будет содержимое нашего файла CSV в этой области в Excel. Последний шаг — скопировать (Ctrl+C) те новые ячейки, которые по умолчанию выбираются автоматически, и вставить (Ctrl+V) в первую позицию таблицы.

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

Важное примечание. Мы должны изменить порядок столбцов на листе Official-VMFlexibilityGroups. Первый столбец должен быть ArmSkuName, второй InstanceSizeFlexibilityGroup, а затем Ratio. Основная причина в том, что мы делаем много в Excel, и нам нужно переключать эти столбцы. Порядок первого столбца также должен быть восходящим.

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

Определение семейного стандарта для вашей подписки

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

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

На втором шаге мы перейдем на лист Official-FlexibilityGroups и скопируем только значения столбца ArmSkuName всех типов виртуальных машин семейства, которые я выбрал на предыдущем шаге (пункт 2).

Третий шаг — самый простой, и мы переименуем вертикальную ячейку (столбец I), чтобы она соответствовала имени (пункт 3).

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

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

Результатом станет таблица «Текущие цифры» с моими первоначальными предложениями по корпоративному/подписному стандарту (пункт 1). В этой же области мы можем видеть все доступные виртуальные машины, включая ЦП, память, диски данных и их соотношение. У нас также есть сводка по общим числам (элемент 2), и мы можем использовать Excel, чтобы выполнить пару простых математических операций, чтобы узнать, сколько экземпляров нужно изменить, если мы решим применить текущее предложение.

Планирование переноса зарезервированных экземпляров

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

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

• Используйте ЦП, а для изменения размера ВМ требуется как минимум столько же ЦП, сколько доступно для ВМ.
• Используйте память, а для изменения размера виртуальной машины требуется как минимум такой же объем памяти, доступный для виртуальной машины.
• Стоимость использования, цена новой ВМ должна быть ниже существующей.

В мы собираемся отслеживать тип изменения. Имейте в виду, что столбцы элемента 1 уже были загружены в начале этой статьи. Единственные необходимые изменения, которые нам нужно внести, — это те два столбца, которые выделены в пункте 2.

Столбец — это визуальный индикатор, введите 1 для обновления, 5 для отсутствия изменений и 10 для перехода на более раннюю версию существующего экземпляра виртуальной машины. В столбце New Size введите размер виртуальной машины, и все остальные расчеты будут выполнены автоматически.

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