Поделиться через


Оптимизация затрат в База данных Azure для PostgreSQL — гибкий сервер

ОБЛАСТЬ ПРИМЕНЕНИЯ: База данных Azure для PostgreSQL — гибкий сервер

База данных Azure для PostgreSQL гибкий сервер — это служба реляционной базы данных в облаке Майкрософт на основеPostgreSQL Community Edition.. Это полностью управляемая база данных как услуга, которая может обслуживать критически важные рабочие нагрузки, обеспечивая прогнозируемую производительность и динамическое масштабирование.

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

  • Используйте цены на зарезервированную емкость.
  • Масштабирование вычислений вверх или вниз.
  • Использование рекомендаций помощника по Azure.
  • Оцените требования высокого уровня доступности (высокий уровень доступности) и аварийного восстановления (аварийное восстановление).
  • Консолидация баз данных и серверов.
  • Поместите тестовые серверы в экономически эффективные географические регионы.
  • Запуск и остановка серверов.
  • Архивируйте старые данные для холодного хранилища.

1. Использование цен на зарезервированную емкость

Цены на зарезервированную емкость Azure Postgres позволяют фиксировать определенную емкость в течение 1–3 лет, экономя затраты для клиентов с помощью База данных Azure для PostgreSQL гибкого сервера. Экономия затрат по сравнению с ценами на оплату по мере использования может быть значительной в зависимости от объема зарезервированной емкости и продолжительности срока. Клиенты могут приобрести зарезервированную емкость в добавках виртуальных ядер и хранилища. Зарезервированная емкость может покрыть расходы на База данных Azure для PostgreSQL гибких экземпляров сервера в том же регионе, примененных к подписке Azure клиента. Зарезервированные цены на База данных Azure для PostgreSQL гибком сервере обеспечивают экономию затрат до 40% в течение 1 года и до 60% для 3-летних обязательств для клиентов, которые резервировали емкость. Дополнительные сведения см. в калькуляторе цен | Microsoft Azure. Дополнительные сведения см. в статье "Что такое резервирования Azure"?

2. Увеличение и уменьшение масштаба вычислений

Масштабирование ресурсов База данных Azure для PostgreSQL гибкого экземпляра сервера может помочь оптимизировать затраты. Настройте виртуальные ядра и хранилище по мере необходимости, чтобы платить только за необходимые ресурсы. Масштабирование можно выполнить с помощью портал Azure, Azure CLI или REST API Azure. Масштабирование вычислительных ресурсов вверх или вниз может выполняться в любое время и требует перезагрузки сервера. Рекомендуется отслеживать шаблоны использования базы данных и настраивать ресурсы соответствующим образом, чтобы оптимизировать затраты и обеспечить производительность. Дополнительные сведения см. в разделе "Параметры вычислений и хранилища" в База данных Azure для PostgreSQL гибком сервере.

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

Дополнительные сведения см. в статье "Масштабирование операций" на гибком сервере База данных Azure для PostgreSQL

3. Использование рекомендаций помощника по Azure

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

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

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

4. Оценка высокого уровня доступности (высокий уровень доступности) и аварийного восстановления (аварийное восстановление)

База данных Azure для PostgreSQL гибкий сервер имеет встроенную устойчивость узла и хранилища без дополнительных затрат. Устойчивость узлов позволяет База данных Azure для PostgreSQL гибким экземпляром сервера автоматически отработки отказа на здоровую виртуальную машину без потери данных (то есть нулю RPO) и без строка подключения изменений, за исключением того, что приложение должно повторно подключиться. Аналогичным образом журналы данных и транзакций хранятся в трех синхронных копиях, и он автоматически обнаруживает повреждение хранилища и принимает корректирующее действие. Для большинства рабочих нагрузок разработки и тестирования и для многих рабочих нагрузок эта конфигурация должна быть достаточной.

Если для рабочей нагрузки требуется устойчивость AZ и более низкая RTO, вы можете включить высокий уровень доступности (HA) в режиме "в зоне" или в режиме ожидания между AZ. Это удвоит затраты на развертывание, но также обеспечивает более высокий уровень обслуживания. Чтобы обеспечить геостойкость для приложения, вы можете настроить GeoBackup для более низкой стоимости, но с более высоким уровнем RTO. Кроме того, вы можете настроить GeoReadReplica для двойной стоимости, которая предлагает RTO в минутах, если произошла геокатастика.

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

Дополнительные сведения см. в статье [Архитектура высокого уровня доступности в гибком сервере]/azure/надежность/надежность-postgresql-гибкий сервер

5. Консолидация баз данных и серверов

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

  1. Доступ к серверу: определите сервер, который можно объединить, учитывая размер базы данных, георегион, конфигурацию (ЦП, память, операции ввода-вывода в секунду), требования к производительности, тип рабочей нагрузки и потребности в согласованности данных.
  2. Создайте новый экземпляр гибкого сервера База данных Azure для PostgreSQL: создайте новый экземпляр гибкого сервера База данных Azure для PostgreSQL с достаточным количеством виртуальных ЦП, памяти и хранилища для поддержки объединенных баз данных.
  3. Повторно используйте существующий База данных Azure для PostgreSQL гибкий экземпляр сервера: если у вас уже есть существующий сервер, убедитесь, что у него достаточно виртуальных ЦП, памяти и хранилища для поддержки объединенных баз данных.
  4. Перенос баз данных: перенос баз данных в новый База данных Azure для PostgreSQL гибкий экземпляр сервера. Для экспорта и импорта баз данных можно использовать такие средства, как pg_dump и pg_restore.
  5. Мониторинг производительности. Отслеживайте производительность консолидированного База данных Azure для PostgreSQL гибкого экземпляра сервера и настройте ресурсы по мере необходимости, чтобы обеспечить оптимальную производительность.

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

Дополнительные сведения см. в статье "Повышение производительности приложений Azure с помощью Помощника по Azure"

6. Размещение тестовых серверов в экономически эффективных георегиационных регионах

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

  1. Определите экономичный регион: определите регион Azure с более низкой стоимостью вычислительных ресурсов.
  2. Создайте новый База данных Azure для PostgreSQL гибкий экземпляр сервера: создайте новый База данных Azure для PostgreSQL гибкий экземпляр сервера в экономичном регионе с правильной конфигурацией для тестовой среды.
  3. Перенос тестовых данных. Перенос тестовых данных в новый экземпляр гибкого сервера База данных Azure для PostgreSQL. Для экспорта и импорта баз данных можно использовать такие средства, как pg_dump и pg_restore.
  4. Мониторинг производительности. Отслеживайте производительность тестового сервера и настройте ресурсы по мере необходимости, чтобы обеспечить оптимальную производительность.

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

Дополнительные сведения см. в регионах Azure

7. Запуск и остановка серверов

Запуск и остановка серверов может быть стратегией экономии затрат для База данных Azure для PostgreSQL гибкого сервера. Запустив сервер только при необходимости, вы можете сократить затраты на выполнение База данных Azure для PostgreSQL гибкого сервера. Ниже приведены несколько шагов, которые помогут вам начать и остановить серверы и сэкономить затраты.

  1. Определите сервер: определите База данных Azure для PostgreSQL гибкий экземпляр сервера, который требуется запустить и остановить.
  2. Запустите сервер: запустите База данных Azure для PostgreSQL гибкий экземпляр сервера при необходимости. Сервер можно запустить с помощью портал Azure, Azure CLI или REST API Azure.
  3. Остановите сервер. Остановите База данных Azure для PostgreSQL гибкий экземпляр сервера, если он не нужен. Сервер можно остановить с помощью портал Azure, Azure CLI или REST API Azure.
  4. Кроме того, если сервер был в состоянии остановленного (или бездействия) в течение нескольких непрерывных недель, можно рассмотреть возможность удаления сервера после необходимой проверки.

При необходимости запуска и остановки сервера можно сократить затраты на выполнение База данных Azure для PostgreSQL гибкого сервера. Чтобы обеспечить плавную производительность базы данных, важно оценить влияние запуска и остановки сервера и обеспечить надежный процесс для этих действий по мере необходимости. Дополнительные сведения см. в статье "Остановка экземпляра База данных Azure для PostgreSQL гибкого сервера" и запуск экземпляра База данных Azure для PostgreSQL гибкого сервера.

8. Архивация старых данных для холодного хранилища

Архивация редко доступ к данным в хранилище архивов Azure (при сохранении доступа) может помочь сократить затраты. Экспортируйте данные из База данных Azure для PostgreSQL гибкого сервера в архивное хранилище Azure и сохраните их на более низком уровне хранилища.

  1. Настройте учетную запись Хранилище BLOB-объектов Azure и создайте контейнер для резервных копий базы данных.
  2. Используется pg_dump для экспорта старых данных в файл.
  3. Используйте Azure CLI или PowerShell для отправки экспортированного файла в контейнер хранилища BLOB-объектов.
  4. Настройте политику хранения в контейнере хранилища BLOB-объектов для автоматического удаления старых резервных копий.
  5. Измените скрипт резервного копирования, чтобы экспортировать старые данные в хранилище BLOB-объектов вместо локального хранилища.
  6. Проверьте процесс резервного копирования и восстановления, чтобы убедиться, что архивные данные можно восстановить при необходимости.

Вы также можете использовать Фабрика данных Azure для автоматизации этого процесса.

Дополнительные сведения см. в статье "Миграция гибкой базы данных сервера База данных Azure для PostgreSQL с помощью дампа и восстановления"

Компромиссы по стоимости

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

Затраты и надежность

Стоимость имеет прямую корреляцию с надежностью.

Затраты и эффективность производительности

Повышение производительности приводит к увеличению затрат.

Затраты и безопасность

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

Затраты и эффективность работы

Инвестиции в мониторинг систем и автоматизацию могут сначала увеличить стоимость, но со временем уменьшат ее.