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

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

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

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

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

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

• Восстановление емкости.
• Перенос объектов хранилища.

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

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

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

Диски

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

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

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

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

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

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

Важный

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

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

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

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

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

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

Блобы и контейнеры

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

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

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

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

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

Объемы

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

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

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

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

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

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

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

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

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

Существует три средства мониторинга объёма данных.

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

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

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

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

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

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

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

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

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

   

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

Оповещения о пространстве хранилища

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

Важный

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

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

  пример

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

  пример

• Просмотреть сведения: в администраторском портале можно открыть детали оповещения для просмотра вариантов устранения:

  

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

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

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

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

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

Чтобы просмотреть метрики емкости томов в Azure Monitor, следуйте этим шагам.

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

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

3. Создайте JSON-файл панели мониторинга емкости, выполнив следующую команду в CapacityManagement:

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

   Эта команда создает json-файл, начинающийся с DashboardVolumeObjStore в папке DashboardGenerator.

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

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

   

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

   

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

   

Шаблоны использования объёмов.

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

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

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

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

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

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

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

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

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

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

Восстановление емкости

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

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

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

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

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

Важный

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

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

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

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. Вы можете отменить задание миграции в процессе выполнения. Отмененные задания миграции обрабатываются асинхронно. Вы можете отслеживать отмену с помощью имени задания, пока состояние не подтвердит, что задание миграции отменено:

   Stop-AzsDiskMigrationJob -Name $jobName
   

   пример

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

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

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

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 Hub приводит к увеличению резерва устойчивости в дополнение к увеличению памяти самой виртуальной машины.

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

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

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

Ознакомьтесь со вкладкой "Емкость" (,) для физической памяти, как показано на следующем изображении, и значение "Использовано" (,) включает резерв устойчивости. Этот график из четырехузлового экземпляра Azure Stack Hub.

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

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

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