Управление емкостью хранилища для Azure Stack Hub

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

Как у оператора облака, у вас есть ограниченный объем хранилища для работы. Объем хранилища определяется реализуемым решением. Решение предоставляется поставщиком изготовителя оборудования при использовании решения с несколькими узлами или обеспечивается оборудованием, на котором устанавливается Пакет средств разработки Azure Stack (ASDK).

Azure Stack Hub поддерживает только расширение емкости хранилища путем добавления дополнительных узлов единиц масштабирования. Дополнительные сведения см. в статье Добавление узлов единиц масштабирования в Azure Stack Hub. Добавление физических дисков к узлам не приведет к расширению емкости хранилища.

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

Ниже перечислены возможные варианты управления емкостью:

• освобождение емкости;
• миграция объектов хранилища.

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

Общие сведения о дисках, контейнерах и томах

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

Диски

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

Управляемые диски упрощают управление дисками виртуальных машин Azure IaaS. Они управляют учетными записями хранения, связанными с этими дисками. Вам нужно только выбрать размер диска, а Azure Stack Hub самостоятельно создаст диск и будет управлять им. Дополнительные сведения см. в статье Обзор управляемых дисков.

Неуправляемые диски — это VHD-файлы , которые хранятся в виде страничных BLOB-объектов в контейнерах хранилища в учетных записях хранения Azure Stack. Созданные клиентами страничные BLOB-объекты называются дисками виртуальной машины и хранятся в контейнерах в учетных записях хранения. Мы рекомендуем использовать неуправляемые диски только для виртуальных машин, которые должны быть совместимы со сторонними инструментами, которые поддерживают только неуправляемые диски Azure.

Клиенты должны размещать каждый диск в отдельном контейнере для повышения производительности виртуальной машины.

• Каждый контейнер, хранящий диск виртуальной машины (страничный BLOB-объект), считается контейнером, подключенным к виртуальной машине, которой принадлежит диск.
• Контейнер, который не содержит дисков виртуальных машин, считается свободным контейнером.

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

Важно!

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

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

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

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

Диски часто создаются путем копирования из образов платформы, управляемых образов, моментальных снимков или других дисков. Моментальные снимки создаются с дисков. Чтобы увеличить использование емкости хранилища и сократить время копирования, система использует блочное клонирование в ReFS. Клонирование BLOB-объектов — это недорогие операции с метаданными, а не полное байтовое копирование между файлами. Исходный и целевой файлы могут совместно использовать одинаковые экстенты, идентичные данные физически не хранятся несколько раз, что повышает емкость хранилища.

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

Большие двоичные объекты и контейнеры

Пользователи клиента хранят большие объемы неструктурированных данных с помощью BLOB-объектов Azure. Azure Stack Hub поддерживает три типа BLOB-объектов: блочные, добавочные и страничные BLOB-объекты. Дополнительные сведения о различных больших двоичных объектах см. в статье Understanding Block Blobs, Append Blobs, and Page Blobs (Основные сведения о блочных, добавочных и страничных BLOB-объектах).

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

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

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

Когда используется 90 % (а затем 95 %) доступного пространства в томе, система выдает оповещения на портале администрирования Azure Stack Hub. Операторам облака необходимо просмотреть доступную емкость хранилища и запланировать перераспределение содержимого. Служба хранения перестает работать, когда диск используется на 100 %. Никакие дополнительные оповещения не поступают.

Тома

Служба хранения разделяет доступное хранилище на отдельные тома, которые выделены для хранения данных клиента и системы. Тома объединяют диски в пул хранения, чтобы обеспечить отказоустойчивость, масштабируемость и производительность локальных дисковых пространств. Дополнительные сведения о томах в Azure Stack Hub см. в статье Управление инфраструктурой хранилища для Azure Stack Hub.

Тома хранилища объектов хранят данные арендатора. К данным клиента относятся страничные BLOB-объекты, блочные BLOB-объекты, добавочные большие двоичные объекты, таблицы, очереди, базы данных и связанные хранилища метаданных. Количество томов хранилища объектов равно количеству узлов в развертывании Azure Stack Hub:

• В развертывании с четырьмя узлами находятся четыре тома хранилища объектов. В развертывании с несколькими узлами количество томов не уменьшается, если узел удален или неисправен.
• При использовании ASDK существует один том с одной общей папкой.

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

Так как объекты хранилища (BLOB-объекты и т. д.) содержатся в одном томе по отдельности, максимальный размер каждого объекта не может превышать размер тома. Максимальный размер новых объектов зависит от емкости, которая остается в томе в качестве неиспользуемого пространства при создании нового объекта.

Если в томе хранилища объектов недостаточно свободного пространства, а вам не удалось освободить место или этот вариант недоступен, оператор облака Azure Stack Hub может перенести объекты хранилища из одного тома в другой.

См. дополнительные сведения о том, как пользователи клиента взаимодействуют с хранилищем BLOB-объектов в Azure Stack Hub.

Мониторинг хранилища

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

Существует три средства для мониторинга емкости тома:

• Портал и PowerShell для текущей емкости тома.
• Оповещения о дисковом пространстве.
• Метрики емкости тома.

В этом разделе мы рассмотрим, как использовать эти средства для мониторинга емкости системы.

Использование PowerShell

Как оператор облака вы можете отслеживать емкость хранилища в томе с помощью командлета PowerShell Get-AzsVolume. Этот командлет возвращает объем общего и свободного пространства в гигабайтах (ГБ) для каждого тома.

• Общая емкость: Общее пространство в ГБ, доступное в общей папке. Это пространство используется для данных и метаданных, обрабатываемых службами хранения.
• Оставшаяся емкость: Объем свободного пространства в ГБ для хранения данных клиента и связанных метаданных.

Использование портала администрирования

Как оператор облака вы можете использовать портал администрирования для просмотра емкости всех томов.

1. Войдите на портал администрирования Azure Stack Hub (https://adminportal.local.azurestack.external).

2. Выберите Все службы>Тома хранилища>, чтобы открыть списоктомов, в котором можно просмотреть сведения об использовании.

   

   • Total: Общее доступное пространство в томе. Это пространство используется для данных и метаданных, обрабатываемых службами хранения.
   • Используется. Объем данных, используемый всеми экстентами из файлов, в которых хранятся данные арендатора и связанные метаданные.

Оповещения о дисковом пространстве

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

Важно!

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

• Предупреждение. Если общая папка используется более чем на 90 %, на портале администрирования отображается предупреждение:

  

• Критическое. Если общая папка используется более 95 %, вы получите критическое оповещение на портале администрирования:

  

• Просмотр сведений. На портале администрирования можно открыть сведения об оповещении, чтобы просмотреть варианты устранения его причины.

  

Метрики емкости тома

Метрики емкости томов предоставляют более подробные сведения о подготовленной емкости и используемой емкости для различных типов объектов. Данные метрик сохраняются в течение 30 дней. Служба фонового мониторинга обновляет данные метрик емкости тома ежечасно.

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

Azure Monitor предоставляет следующие метрики для отображения использования емкости тома:

• Общая емкость тома показывает общую емкость хранилища тома.
• Оставшаяся емкость тома показывает оставшуюся емкость тома.
• Занятая емкость диска виртуальной машины тома показывает общее количество пробелов, занятых объектами, связанными с диском виртуальной машины (включая страничные BLOB-объекты, управляемые диски/snapshot, управляемые образы и образы платформы). Базовый VHD-файл дисков виртуальных машин может использовать одинаковый экстент (см. раздел Диски) с образами, моментальными снимками или другими дисками. Это число может быть меньше суммы используемой емкости всех отдельных объектов, связанных с диском виртуальной машины.
• Другая используемая емкость тома — это общий используемый размер объектов, отличных от дисков, включая блочные BLOB-объекты, добавочные BLOB-объекты, таблицы, очереди и метаданные BLOB-объектов.
• Емкость подготовленного диска виртуальной машины тома — это общий подготовленный размер страничных BLOB-объектов и управляемых дисков и моментальных снимков. Этот размер является максимальным значением общей емкости дисков всех управляемых дисков и страничных BLOB-объектов на определенном томе, до который может увеличиться.

Чтобы просмотреть метрики емкости томов в Azure Monitor, выполните приведенные далее действия.

1. Проверьте, установлена и настроена ли среда Azure PowerShell. Инструкции по настройке среды PowerShell приведены в статье Установка PowerShell для Azure Stack Hub. Сведения о том, как войти в Azure Stack Hub, см. в статье Подключение к Azure Stack с помощью PowerShell.

2. Скачайте средства Azure Stack Hub из репозитория GitHub. Подробные инструкции см. в статье Скачивание средств Azure Stack Hub с сайта GitHub.

3. Создайте json панели мониторинга емкости, запустив DashboardGenerator в разделе CapacityManagement.

   .\CapacityManagement\DashboardGenerator\Create-AzSStorageDashboard.ps1 -capacityOnly $true -volumeType object
   

   В папке DashboardGenerator будет находиться json-файл с именем DashboardVolumeObjStore .

4. Войдите на портал администрирования Azure Stack Hub (https://adminportal.local.azurestack.external).

5. На странице Панели мониторинга щелкните Отправить и выберите JSON-файл, созданный на шаге 3.

   

6. После отправки json вы будете перенаправлены на новую панель мониторинга емкости. Каждый том имеет соответствующую диаграмму на панели мониторинга. Количество диаграмм равно количеству томов:

   

7. Щелкнув один из томов, можно проверка пять метрик емкости конкретного тома на подробной диаграмме:

   

Шаблоны использования томов

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

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

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

Чрезмерная подготовка, низкая емкость: оставшаяся емкость тома низкая, а емкость диска виртуальной машины и используемого диска виртуальной машины высока.

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

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

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

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

Управление доступным местом

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

Освобождение емкости

Можно освободить емкость, используемую учетными записями арендатора, которые были удалены. Эта емкость автоматически освобождается при истечении срока хранения данных (или же вы можете немедленно освободить ее).

Дополнительные сведения см. в подразделе "Освобождение емкости" раздела Управление учетными записями хранения Azure Stack Hub.

Миграция управляемого диска между томами

Этот параметр применяется только к интегрированным системам Azure Stack Hub.

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

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

Важно!

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

Миграция управляемых дисков с помощью PowerShell

1. Проверьте, установлена и настроена ли среда Azure PowerShell. Инструкции по настройке среды PowerShell приведены в статье Установка PowerShell для Azure Stack Hub. Сведения о том, как войти в Azure Stack Hub, см. в статье Подключение к Azure Stack с помощью PowerShell.

2. Проверьте управляемые диски, чтобы понять, какие из них находятся в томе, который вы планируете перенести. Чтобы определить наиболее подходящие для переноса диски в томе, используйте командлет Get-AzsDisk.

   $ScaleUnit = (Get-AzsScaleUnit)[0]
   $StorageSubSystem = (Get-AzsStorageSubSystem -ScaleUnit $ScaleUnit.Name)[0]
   $Volumes = (Get-AzsVolume -ScaleUnit $ScaleUnit.Name -StorageSubSystem $StorageSubSystem.Name | Where-Object {$_.VolumeLabel -Like "ObjStore_*"})
   $SourceVolume  = ($Volumes | Sort-Object RemainingCapacityGB)[0]
   $VolumeName = $SourceVolume.Name.Split("/")[2]
   $VolumeName = $VolumeName.Substring($VolumeName.IndexOf(".")+1)
   $MigrationSource = "\\SU1FileServer."+$VolumeName+"\SU1_"+$SourceVolume.VolumeLabel
   $Disks = Get-AzsDisk -Status OfflineMigration -SharePath $MigrationSource | Select-Object -First 10
   

   Затем проверьте значение $disks.

   $Disks
   

   

3. Определите наиболее подходящие целевые тома для хранения переносимых дисков.

   $DestinationVolume  = ($Volumes | Sort-Object RemainingCapacityGB -Descending)[0]
   $VolumeName = $DestinationVolume.Name.Split("/")[2]
   $VolumeName = $VolumeName.Substring($VolumeName.IndexOf(".")+1)
   $MigrationTarget = "\\SU1FileServer."+$VolumeName+"\SU1_"+$DestinationVolume.VolumeLabel
   

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

   $jobName = "MigratingDisk"
   Start-AzsDiskMigrationJob -Disks $Disks -TargetShare $MigrationTarget -Name $jobName
   

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

   $job = Get-AzsDiskMigrationJob -Name $jobName
   

   

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

   $job.Subtask
   

   

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

   Stop-AzsDiskMigrationJob -Name $jobName
   

   

Распределение неуправляемых дисков

Этот параметр применяется только к интегрированным системам Azure Stack Hub.

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

Память, доступная для виртуальных машин

Azure Stack Hub создается как гиперконвергентный кластер вычислений и хранилища. Конвергенция позволяет совместно использовать оборудование, называемое единицей масштабирования. В Azure Stack Hub единицы масштабирования обеспечивают доступность и масштабируемость ресурсов. Единица масштабирования состоит из набора серверов Azure Stack Hub, называемых узлами или узлами. Программное обеспечение инфраструктуры размещается в наборе виртуальных машин на тех же физических серверах, что и виртуальные машины клиента. Все виртуальные машины Azure Stack Hub затем управляются технологиями windows Server кластеризация единицы масштабирования и отдельными экземплярами Hyper-V. Использование единиц масштабирования упрощает получение и администрирование ресурсов Azure Stack Hub. Единица масштабирования также позволяет перемещать и масштабировать все службы в Azure Stack Hub, клиенте и инфраструктуре.

Вы можете просмотреть круговую диаграмму на портале администрирования, которая показывает свободную и используемую память в Azure Stack Hub, как показано ниже:

Следующие компоненты потребляют память в разделе используемой круговой диаграммы:

• Использование или резервирование ОС узла Это память, используемая операционной системой (ОС) на узле, таблицами страниц виртуальной памяти, процессами, выполняющимися в ОС узла, и кэшем памяти с прямыми пробелами. Так как это значение зависит от памяти, используемой другими работающими на узле процессами Hyper-V, оно может меняться.
• Службы инфраструктуры Это виртуальные машины инфраструктуры, составляющие Azure Stack Hub. Это означает, что примерно 31 виртуальная машина занимает 242 ГБ + (4 ГБ x количество узлов) памяти. Объем памяти, используемый компонентом служб инфраструктуры, может измениться, так как мы работаем над улучшением масштабируемости и устойчивости служб инфраструктуры.
• Резерв устойчивости Azure Stack Hub резервирует часть памяти, чтобы обеспечить доступность клиента во время сбоя одного узла, а также во время исправления и обновления, чтобы обеспечить успешную динамическую миграцию виртуальных машин.
• Виртуальные машины клиента Это виртуальные машины, созданные пользователями Azure Stack Hub. Наряду с работающими виртуальными машинами память также потребляют виртуальные машины, которые работают в структуре. Это означает, что виртуальные машины, которые находятся в состоянии Создание или Сбой, либо работа которых завершена из гостевой ОС, также будут потреблять памяти. Тем не менее виртуальные машины, которые были освобождены с помощью параметра остановить освобождение на пользовательском портале Azure Stack Hub, PowerShell и Azure CLI, не будут потреблять память из Azure Stack Hub.
• Поставщики ресурсов надстройки Виртуальные машины, развернутые для поставщиков ресурсов надстройки, таких как SQL, MySQL и Служба приложений.

Доступная память для размещения виртуальной машины

Как оператор облака для Azure Stack Hub не существует автоматизированного способа проверка выделенной памяти для каждой виртуальной машины. Вы можете получить доступ к пользовательским виртуальным машинам и вычислить выделенную память вручную. Однако выделенная память не будет отражать реальное использование. Это значение может быть ниже выделенного значения.

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

Доступная память для размещения виртуальной машины = Total Host Memory--Resiliency Reserve--Memory used by running tenant VMs - Azure Stack Hub Infrastructure Overhead

Резерв устойчивости = H + R * ((N-1) * H) + V * (N-2)

Где:

H = размер памяти с одним узлом

N = размер единицы масштабирования (количество узлов)

R = резерв/память операционной системы, используемая ОС узла, которая в этой формуле имеет значение 0,15.

V = крупнейшая виртуальная машина (с точки зрения памяти) в единице масштабирования

Накладные расходы на инфраструктуру Azure Stack Hub = 242 ГБ + (4 ГБ x число узлов). Это примерно 31 виртуальная машина, используемая для размещения инфраструктуры Azure Stack Hub.

Объем памяти, используемый ОС узла , составляет 15 % (0,15) объема памяти узла. Значение резерва операционной системы является оценочным и будет зависеть от объема физической памяти узла и общих затрат операционной системы.

Значение V, самая большая виртуальная машина в единице масштабирования, динамически зависит от развернутой самой большой виртуальной машины клиента. Например, это значение может быть равно 7 ГБ, 112 ГБ или соответствовать другому размеру памяти виртуальной машины, поддерживаемому решением Azure Stack Hub. Мы выбрали размер самой большой виртуальной машины, чтобы иметь достаточно памяти, чтобы динамическая миграция этой большой виртуальной машины не завершилась сбоем. Изменение самой большой виртуальной машины в структуре Azure Stack приведет к увеличению резерва для устойчивости, а также увеличению объема памяти самой виртуальной машины.

Например, с единицей масштабирования 12 узлов:

Сведения о метки	Значения
sts (N)	12
Память на узел (H)	384
Общий объем памяти единицы масштабирования	4608
Резерв ОС (R)	15 %
Крупнейшая виртуальная машина (V)	112
Резерв устойчивости =	H + R * ((N-1) * H) + V * (N-2)
Резерв устойчивости =	2137.6

Таким образом, с помощью приведенных выше сведений можно вычислить, что в Azure Stack с 12 узлами по 384 ГБ на узел (всего 4608 ГБ) зарезервировано 2137 ГБ для обеспечения устойчивости, если самая большая виртуальная машина имеет 112 ГБ памяти.

При просмотре колонки Емкость для физической памяти, как показано ниже, значение Использовано включает резерв устойчивости. Граф получен из экземпляра Azure Stack Hub с четырьмя узлами.

Учитывайте эти рекомендации при планировании емкости для Azure Stack Hub. Кроме того, можно использовать Планировщик ресурсов Azure Stack Hub.

Дальнейшие действия

Дополнительные сведения о предложениях виртуальных машин для пользователей см. в статье Управление емкостью хранилища для Azure Stack Hub.