Оптимизация затрат после миграции
После переноса рабочих нагрузок в Azure необходимо оптимизировать затраты, чтобы убедиться, что вы не перерасходите ресурсы. В этой статье описано, как оптимизировать затраты после миграции и как вывести из эксплуатации устаревшие активы с минимальными перерывами в бизнесе.
Оптимизация перенесенных рабочих нагрузок для затрат
После переноса рабочих нагрузок и списания ненужных ресурсов можно сэкономить на затратах, оптимизируя рабочую нагрузку на основе его динамических данных.
Вы можете изменить размер рабочих нагрузок на основе их производительности во время оценки, но вы можете найти во время выполнения рабочей нагрузки в Azure, что существует дополнительная экономия затрат.
Средства оптимизации затрат
После миграции в Azure у вас есть новые средства для управления затратами на ресурсы. Используйте следующий список для управления затратами в облаке.
Средство | Description | Ресурс |
---|---|---|
Ресурсы rightsize | Просмотрите метрики использования службы и укажите их права на соответствие требованиям рабочей нагрузки. | |
Azure Reserved Virtual Machine Instances | Зарезервированные экземпляры позволяют выполнять фиксацию ресурсов в Azure, которые выполняются часто. Рекомендуется резервировать экземпляры для рабочих нагрузок, которые всегда активны. | |
Планы экономии Azure | Планы экономии Azure обеспечивают экономию до 65% по сравнению с ценами на оплату по мере использования при фиксации расходов на почасовую сумму на вычислительные службы в течение одного или трех лет. | |
Управление затратами | Управление затратами Майкрософт позволяет отслеживать затраты среды и управлять ими. | |
Документация по финансовым операциям | Финансовые операции — это дисциплина, которая объединяет принципы финансового управления с облачными технологиями и операциями, чтобы обеспечить организациям лучшее понимание своих облачных расходов. |
Списание ресурсов, использование которых прекращено
После повышения уровня перенесенной рабочей нагрузки в рабочую среду ресурсы, на которых запущена рабочая нагрузка, больше не требуются и считаются не в обслуживании. Но эти активы по-прежнему потребляют электроэнергию и другие ресурсы, что увеличивает затраты. Поэтому рекомендуется завершить работу и удалить устаревшие активы, чтобы сократить расходы.
Завершение работы и удаление старых активов и оборудования может показаться простым, но непредвиденные проблемы могут возникнуть. Ниже приведены некоторые советы по безопасному закрытию и удалению старых ресурсов без каких-либо проблем для вашего бизнеса.
Продолжить мониторинг
После продвижения перенесенной рабочей нагрузки в рабочую среду следует продолжать отслеживать ресурсы, запланированные для выхода на пенсию, чтобы обеспечить правильность маршрутизации рабочего трафика.
Хотя ресурсы могут быть отключены, они по-прежнему могут использовать хранилище, сеть и другие ресурсы инфраструктуры. Если они снова включено, они могут вызвать непредвиденные проблемы, если они не были удалены.
Отслеживайте следующие сигналы для ресурсов:
- Вычисления: использование вычислительных ресурсов, таких как ЦП и ОЗУ.
- служба хранилища: использование хранилища ресурсов, например ввод и вывод диска (ввода-вывода).
- Сеть: использование сети ресурсов, включающее входящий и исходящий сетевой трафик из (модуль). Например, проверьте ресурсы, использующие брандмауэры и подсистемы балансировки нагрузки для обмена данными.
- Журналы: журналы Windows и приложений.
- Другие сигналы: любые другие сигналы, которые вы использовали для мониторинга активов, когда они были размещены в предыдущей рабочей среде.
В некоторых миграциях ресурсы не отключены. Вместо этого они дублируются. Внезапные пики или даже консервы режим палатки скорости использования сигналов инфраструктуры, а также сетевых действий или новых журналов, могут указывать на то, что ресурс по-прежнему используется.
Периоды тестирования и проверка зависимостей
Даже при оптимальном планировании рабочие нагрузки могут по-прежнему содержать зависимости от ресурсов, которые считаются устаревшими. В таких случаях отключение отставного ресурса может вызвать непредвиденный сбой системы. Таким образом, следует рассматривать прекращение любых активов с той же осторожностью, что и действия по обслуживанию системы.
Установите надлежащие окна тестирования и сбоя, чтобы упростить завершение работы ресурса. Вам потребуется период обслуживания, чтобы успешно протестировать ресурсы перед завершением работы. Выберите период времени, когда можно протестировать ресурсы без каких-либо перерывов в бизнесе.
Определение периода тестирования и обслуживания
- Время низкого влияния: определение низкого влияния для окна тестирования. Выберите время, когда использование приложения находится на самом низком уровне.
- Очистить тестовые случаи. Определите четкие тестовые случаи, которые можно выполнить во время периода тестирования, соответствующего реальным действиям, выполняемым пользователями приложения. Эти действия не должны быть уровнем поверхности, но вместо этого должны сопоставляться с каждым используемым процессом. Вы можете повторно использовать тестовые варианты из миграции, если у вас их есть. Если у вас есть пользователи или другие участники группы, которые часто работают в приложении, попробуйте выполнить тесты.
- Планирование и обмен данными. Планирование периода обслуживания до тех пор, пока у вас есть доступ. Вы должны стремиться к минимуму четыре часа.
- Расписание. Планирование окна, чтобы пользователи приложений могли заранее планировать. Две недели разумны.
- Общаться: заранее объявите об изменении. Задайте ожидание, что во время этого периода обслуживания может возникнуть сбой и что система может не реагировать. Пользователи не должны ожидать, что приложение будет доступно в течение этого времени.
До периода обслуживания
- Выполните тестовые случаи: выполните тестовые случаи и отслеживайте любое использование ресурсов.
- При обнаружении использования не следует продолжать работу с периодом обслуживания. Вместо этого следует изучить дополнительные сведения о том, используются ли ресурсы.
- Если вы не обнаруживаете использование, вы можете продолжить работу с периодом обслуживания.
Во время периода обслуживания
- Отключение ресурсов: отключите ресурсы, помеченные для вывода из эксплуатации.
- Выключите ресурсы, если они по-прежнему включено.
- Удалите ресурсы из любых подсистем балансировки нагрузки и убедитесь, что они не могут отвечать на входящие запросы.
- Выполнение тестов. Выполните тестовые случаи для рабочей нагрузки, которая выполняется в Azure.
- Тесты успешно выполнены без сбоя: ресурсы не используются в настоящее время.
- Передайте конец окна изменений, чтобы пользователи знали, что они могут ожидать стабильности в приложении снова.
- Перейдите к следующему разделу после успешного выполнения тестов.
- Сбой тестов: ресурсы могут использоваться в настоящее время, и требуется больше тестирования.
- Повторно включите ресурсы, помеченные для вывода из эксплуатации, и повторите неудачные тестовые случаи.
- Если тестовые случаи по-прежнему завершаются ошибкой, может возникнуть не связанная проблема. Вам нужно протестировать больше в течение периода обслуживания, а также начать эскалацию, чтобы убедиться, что у вас есть правильный уровень поддержки.
- Если тестовые случаи перестают завершать сбой, проблема, скорее всего, связана. Вы должны оставить ресурсы включенными и закрыть период обслуживания после завершения тестирования.
- Изучите проблему за пределами запланированного периода обслуживания. Запланируйте еще один период обслуживания для изменений перенесенной рабочей нагрузки и запланируйте дополнительные периоды обслуживания для тестирования.
- Тесты успешно выполнены без сбоя: ресурсы не используются в настоящее время.
Период удержания и проверка данных
После завершения периода тестирования все ресурсы, помеченные для вывода из эксплуатации, должны быть отключены и отключены, чтобы вы могли работать с рабочей нагрузкой. Вы можете перейти к следующему этапу вывода из эксплуатации, но не немедленно удалять активы.
Рассмотрите период хранения
Не редко во время миграции при репликации упускают данные. Это особенно верно для старых данных, к которым не обращаются регулярно. Сохраняйте устаревший ресурс в течение некоторого времени, чтобы служить временной резервной копией данных. Перед удалением устаревших активов необходимо разрешить по крайней мере 30 дней для хранения и тестирования.
Рассмотрите требования к управлению данными
Команда управления данными вашей организации может иметь больше требований за период хранения в течение 30 дней.
- Общие сведения о обязательствах по периоду хранения: вы должны проверка с необходимыми командами, чтобы понять обязательства по удержанию информации и создать список проверка проверки для конкретных юридических требований.
- Наличие актива в настоящее время не важно. Вместо этого данные о информации должны быть извлечены. При необходимости сохраняйте диски или резервные копии, чтобы восстановить данные.
- Например, если у вас есть сервер базы данных SQL в физическом центре обработки данных, вы можете создать резервную копию данных и сохранить его в качестве восстанавливаемого ресурса. Затем можно вывести виртуальную машину из эксплуатации и установить время хранения, чтобы удалить резервную копию.
Следующий шаг
Миграция завершена после вывода из эксплуатации устаревших ресурсов. Это создает хорошую возможность улучшить процесс миграции с ретроспективным для изучения и улучшения.