管理 Azure Stack Hub 的存储容量

你可以作为 Azure Stack Hub 云操作员通过本文来了解如何监视和管理 Azure Stack Hub 部署的存储容量。 可以使用本指南来了解可供用户 VM 使用的内存。 Azure Stack Hub 存储基础结构分配 Azure Stack Hub 部署的一部分总存储容量作为存储服务。 存储服务将租户的数据存储在卷上对应于部署节点的共享中。

云操作员可以使用的存储量有限。 实施的解决方案定义了存储量。 使用多节点解决方案时,解决方案由 OEM 供应商提供,或由安装 Azure Stack 开发工具包 (ASDK) 的硬件提供。

Azure Stack Hub 仅支持通过添加额外缩放单元节点来扩展存储容量。 有关详细信息,请参阅在 Azure Stack Hub 中添加缩放单元节点。 将物理磁盘添加到节点不会扩展存储容量。

请务必监视可用存储,以确保维护有效操作。 当卷的剩余可用容量有限时,请规划管理可用空间以免共享的容量不足。

用于管理容量的选项包括:

  • 回收容量。
  • 迁移存储对象。

当对象存储卷利用率达到 100% 时,不再能够针对该卷运行存储服务。 若要获取卷还原操作的帮助,请联系 Azure 支持部门。

了解磁盘、容器和卷

租户用户在 Azure Stack Hub 存储服务中创建磁盘、blob、表和队列。 这些租户数据放置在可用存储顶部的卷中。

磁盘

VM 存储和处理虚拟磁盘上的数据。 每个 VM 都从使用市场映像或专用映像创建的 OS 磁盘开始。 VM 可以附加零个或多个数据磁盘。 Azure Stack 提供两种类型的磁盘:

托管磁盘通过管理与 VM 磁盘关联的存储帐户简化了 Azure IaaS VM 的磁盘管理。 只需指定所需的磁盘大小,Azure Stack Hub 即可为你创建和管理磁盘。 有关详细信息,请参阅托管磁盘概述

“非托管磁盘”是指以页 blob 形式存储在 Azure Stack 存储帐户的存储容器中的 VHD 文件。 租户创建的页 blob 称为 VM 磁盘并且存储在存储帐户中的容器中。 建议仅对需要与第三方工具(仅支持 Azure 非托管磁盘)兼容的 VM 使用非托管磁盘。

租户最好是将每个磁盘放入不同的容器,以改善 VM 性能。

  • VM 中保存磁盘的每个容器(或页 Blob)被视为拥有此磁盘的 VM 上的附加容器。
  • 不保存 VM 中任何磁盘的容器被视为可用容器。

用于在附加容器中释放空间的选项有限制。 若要了解详细信息,请参阅 分布非托管磁盘

重要

我们建议在 VM 中只使用托管磁盘,以方便进行管理。 在使用托管磁盘之前无需准备存储帐户和容器。 与非托管磁盘相比,托管磁盘提供相同甚至更好的功能和性能。 使用非托管磁盘没有任何优势,它们仅用于实现后向兼容。

托管磁盘经过优化,可以更好地放置在存储基础结构中,并且能够显著减少管理开销。 但由于托管磁盘是精简预配的,其最终利用率在创建时不可预测,因此存在因不均衡的磁盘放置而导致过度利用其容量的可能性。 操作员需负责监视存储容量使用情况并避免出现此类问题。

对于使用 ARM 模板来预配新虚拟机的用户,请使用以下文档了解如何修改模板以使用托管磁盘:使用 VM 托管磁盘模板

VM 磁盘在存储基础结构上存储为稀疏文件。 磁盘的预配大小由用户在创建磁盘时请求。 但是,只有写入磁盘的非零页会占用底层存储基础结构上的空间。

Example: Sparse disk on storage volume.

通常通过从平台映像、托管映像、快照或其他磁盘进行复制来创建磁盘。 快照从磁盘中获取。 为了增加存储容量的利用率并减少复制操作时间,系统会使用 ReFS 中的块克隆。 blob 克隆是一种低成本的元数据操作,而不是在文件之间进行完整的逐字节复制。 源文件和目标文件可以使用相同的盘区,相同数据不会以物理方式存储多次,从而节省存储容量。

Example: Share extent on storage volume.

仅当写入磁盘并且相同数据减少时,容量利用率才会增加。 删除映像或磁盘时,可能无法立即释放空间,因为通过该映像或磁盘创建的磁盘或快照中可能仍保留了相同的数据并占用空间。 只有在删除所有相关实体后,空间才会可用。

Example: Extent after disk deletion.

blob 和容器

租户用户使用 Azure Blob 存储大量非结构化数据。 Azure Stack Hub 支持三种类型的 blob:块 blob、追加 blob 和页 blob。 有关不同类型 Blob 的详细信息,请参阅 Understanding Block Blobs, Append Blobs, and Page Blobs(了解块 Blob、追加 Blob 和页 Blob)。

租户用户可以创建容器用于存储 Blob 数据。 用户可以确定要在哪个容器中放置 Blob,而存储服务使用算法来确定要在哪个卷中放置容器。 此算法通常选择具有最多可用空间的卷。

将 Blob 置于容器中后,该 Blob 可以增长以使用更多空间。 随着新 Blob 的添加和现有 Blob 的增长,卷中保存该容器的可用空间会不断缩减。

容器不限于单个卷。 当容器中合并的 Blob 数据增长为使用 80% 或更多可用空间时,容器将进入溢出模式。 在溢出模式下,在该容器中创建的任何新 Blob 将分配到具有足够空间的其他卷。 一段时间后,处于溢出模式的容器可将 Blob 分布到多个卷。

达到卷中 95% 到 95% 的可用空间时,系统会在 Azure Stack Hub 管理员门户中引发警报。 云操作员应查看可用的存储容量,并规划重新均衡内容。 到达磁盘的 100% 容量时,存储服务将停止运行,但不会引发其他警报。

存储服务将可用的存储分区成独立的卷,这些卷可分配用于保存系统数据和租户数据。 卷将驱动器合并到存储池中,带来存储空间直通的容错、可伸缩性和性能优势。 有关 Azure Stack Hub 中卷的详细信息,请参阅管理 Azure Stack Hub 的存储基础结构

对象存储卷保存租户数据。 租户数据包括页 Blob、块 Blob、追加 Blob、表、队列、数据库和相关的元数据存储。 对象存储卷的数目等于 Azure Stack Hub 部署中的节点数目:

  • 在包含四个节点的部署中,有四个对象存储卷。 在多节点部署中,如果某个节点被删除或出现故障,卷数目不会减少。
  • 如果使用 ASDK,则有一个包含单个共享的卷。

对象存储卷专用于存储服务。 不得直接修改、添加或删除卷上的任何文件。 只能由存储服务处理这些卷中存储的文件。

由于存储对象(Blob 等)各自包含在单个卷中,因此每个对象的大小上限不能超过卷大小。 新对象的大小上限取决于创建新对象时卷中仍未使用的空间容量。

当对象存储卷的可用空间不足且回收空间的操作不成功或不可用时,Azure Stack Hub 云操作人员可以将存储对象从一个共卷迁移到另一个卷。

有关租户用户如何使用 Azure Stack Hub 中的 Blob 存储的详细信息,请参阅 Azure Stack Hub 存储服务

监视存储

使用 Azure PowerShell 或管理员门户来监视共享,以便了解可用空间何时受限。 使用门户时,会收到有关共享空间不足的警报。

使用 PowerShell

云操作员可以使用 PowerShell Get-AzsStorageShare cmdlet 来监视共享的存储容量。 该 cmdlet 返回每个共享中总计、已分配和可用的空间(以字节为单位)。

Example: Return free space for shares.

  • 总容量:共享中可用的总空间(以字节为单位)。 此空间用于存储服务维护的数据和元数据。
  • 已用容量:存储租户数据和相关元数据的文件中所有盘区使用的数据量(以字节为单位)。

使用管理员门户

云操作员可以使用管理员门户来查看所有共享的存储容量。

  1. 登录到管理员门户 https://adminportal.local.azurestack.external

  2. 选择“所有服务”“存储”“文件共享”打开文件共享列表,可以在其中查看使用情况信息。

    Example: Screenshot of storage file shares in Azure Stack Hub administrator portal.

    • Total:共享中可用的总空间(以字节为单位)。 此空间用于存储服务维护的数据和元数据。
    • 已用:存储租户数据和相关元数据的文件中所有盘区使用的数据量(以字节为单位)。

使用 Azure PowerShell 或管理员门户监视已预配和已使用的容量,并规划迁移,以确保系统持续正常运行。

有三种用于监视卷容量的工具:

  • 用于当前卷容量的门户和 PowerShell。
  • 存储空间警报。
  • 卷容量指标。

本部分将介绍如何使用这些工具监视系统的容量。

使用 PowerShell

云操作员可以使用 PowerShell Get-AzsVolume cmdlet 来监视卷的存储容量。 该 cmdlet 返回每个卷中总计和可用的空间 (GB)。

Example: Return free space for volumes.

  • 总容量:共享中可用的总空间 (GB)。 此空间用于存储服务维护的数据和元数据。
  • 剩余容量:可用于存储租户数据和相关元数据的空间量 (GB)。

使用管理员门户

云操作员可以使用管理员门户来查看所有卷的存储容量。

  1. 登录到 Azure Stack Hub 管理员门户 (https://adminportal.local.azurestack.external)。

  2. 选择“所有服务”“存储”“卷”打开卷列表,可以在其中查看使用情况信息。

    Example: Screenshot of storage volumes in Azure Stack Hub administrator portal.

    • Total:卷上可用的空间总量。 此空间用于存储服务维护的数据和元数据。
    • 已用:存储租户数据和相关元数据的文件中所有盘区使用的数据量。

存储空间警报

使用管理员门户时,会收到有关卷空间不足的警报。

重要

云操作员应该避免共享达到用完状态。 当共享利用率达到 100% 时,不再能够针对该共享运行存储服务。 若要在共享利用率达到 100% 时恢复可用空间并还原操作,必须联系 Azure 支持部门。

  • 警告:当文件共享利用率超过 90% 时,管理员门户中会显示“警告”警报:

    Example: Screenshot of warning alert in the Azure Stack Hub administrator portal

  • 严重:当文件共享利用率超过 95% 时,管理员门户中会显示“严重”警报:

    Example: Screenshot of critical alert in the Azure Stack Hub administrator portal

  • 查看详细信息:在管理员门户中,可以打开警报的详细信息来查看缓解选项:

    Example: Screenshot of viewing alert details in the Azure Stack Hub administrator portal

卷容量指标

卷容量指标提供有关不同类型对象的预配容量和已用容量的更多详细信息。 指标数据可保留 30 天。 后台监视服务每小时刷新一次卷容量指标数据。

通过主动查看容量指标报表来了解卷的资源使用情况是很有必要的。 当卷将满时,云操作员可以分析资源类型分布,以确定释放空间的相应操作。 当磁盘预配大小指示卷预配过高时,操作员还可以防止卷被过度使用。

Azure Monitor 提供以下指标来显示卷容量利用率:

  • “卷总容量”显示卷的总存储容量。
  • “卷剩余容量”显示卷的剩余存储容量。
  • “卷 VM 磁盘已用容量”显示 VM 磁盘相关对象(包括页 blob、托管磁盘/快照、托管映像和平台映像)占用的总空间。 VM 磁盘的基础 VHD 文件可以与映像、快照或其他磁盘共享相同的盘区(请参阅磁盘)。 此数值可能小于所有单个 VM 磁盘相关对象的已用容量之和。
  • “卷其他已用容量”是磁盘以外对象(包括块 Blob、追加 Blob、表、队列和 Blob 元数据)的总已用大小。
  • “卷 VM 磁盘预配容量”是页 blob 和托管磁盘/快照的总预配大小。 此大小是特定卷上所有托管磁盘和页 blob 的总磁盘容量可以增长到的最大值。

Example: Volume capacity metrics.

若要在 Azure Monitor 中查看卷容量指标:

  1. 确认已安装并配置 Azure PowerShell。 有关配置 PowerShell 环境的说明,请参阅安装适用于 Azure Stack Hub 的 PowerShell。 若要登录到 Azure Stack Hub,请参阅配置操作员环境并登录到 Azure Stack Hub

  2. GitHub 存储库下载 Azure Stack Hub 工具。 有关详细步骤,请参阅从 GitHub 下载 Azure Stack Hub 工具

  3. 通过在 CapacityManagement 下运行 DashboardGenerator 生成容量仪表板 json。

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

    DashboardGenerator 的文件夹下会有一个名称以 DashboardVolumeObjStore 开头的 json 文件。

  4. 登录到 Azure Stack Hub 管理员门户 (https://adminportal.local.azurestack.external)。

  5. 在“仪表板”页中单击“上传”,然后选择在步骤 3 中生成的 json 文件。

    Example: Upload dashboard json.

  6. 上传 json 后,系统会将你定向到新的容量仪表板。 每个卷在该仪表板中都有相应的图表。 图表数等于卷计数:

    Example: Volume capacity dashboard.

  7. 单击其中一个卷,即可在详细图表中查看该特定卷的五个容量指标:

    Example: Detailed capacity metrics.

卷使用模式

通过查看卷容量指标,云操作员可以了解卷的容量用量,以及占用大部分空间的资源类型。 空间使用模式可以分组为以下类型,操作员应针对每种类型执行不同的操作:

Example: Volume usage pattern.

“备用容量预配过低”:卷上有足够的可用容量,并且此卷上所有磁盘的总预配容量小于总可用容量。 该卷可供更多存储对象使用,包括磁盘和其他对象(块/追加 blob、表和队列)。 无需执行任何操作来处理该卷。

备用容量预配过高:卷的剩余容量较高,但 VM 磁盘预配容量已高于卷总容量。 此卷现在仍有空间可供更多存储对象使用。 但是,此卷上 VM 磁盘中的数据可能会将此卷填满。 应密切监视此卷的使用趋势。 如果变为“预配过高、容量不足”模式,可能需要采取措施来释放空间。

预配过高,容量不足:卷的剩余容量较低,VM 磁盘预配容量和 VM 磁盘已用容量都较高。

剩余容量不足表示卷即将达到全部用量。 操作员需要立即采取措施释放空间,以防止卷利用率达到 100% ,这会阻止存储服务。 VM 磁盘已用容量较高表明 VM 磁盘使用了大部分卷容量。 操作员应参阅迁移磁盘相关说明,将磁盘从容量已满的卷移动到其他可用卷以释放空间。

预配过低,容量不足,块 blob 使用容量高:卷的剩余容量较低,VM 磁盘预配容量和 VM 磁盘已用容量都较低,但其他已用容量较高。

卷有被完全利用的风险,操作员应立即采取措施释放空间。 其他已用容量较高表示块/追加 blob 或表/队列使用了大部分卷容量。 当卷的可用容量小于 20% 时,系统将启用容器溢出,并且不会在此几乎已满的卷上放置新的 Blob 对象。 但现有 blob 可能仍会增加。 若要防止持续增加的 Blob 过度使用容量,可以联系 Azure 支持部门来查询占用特定卷上空间的容器,并决定是否需要由租户清理这些容器以释放一些空间。

预配过高,容量不足,块 blob 使用容量高:卷的剩余容量较低,磁盘已用/预配容量以及其他已用容量均较高。 此卷上的磁盘和其他存储对象均具有较高的空间利用率。 应释放空间以避免卷被完全填满。 建议首先按照迁移磁盘相关说明来将磁盘从容量已满的卷移动到其他可用卷。 在其他情况下,可以联系 Azure 支持部门来查询占用特定卷上空间的容器,并决定是否需要由租户清理这些容器以释放一些空间。

管理可用空间

需要释放卷中的可用空间时,请先使用破坏性最低的方法。 例如,先尝试回收空间,然后再选择迁移托管磁盘。

回收容量

可以回收已删除的租户帐户使用的容量。 当数据达到保留期时,系统会自动回收此容量,或者,你也可以立即回收此容量。

有关详细信息,请参阅管理 Azure Stack Hub 存储帐户的“回收容量”部分。

在卷之间迁移容器

此选项仅适用于 Azure Stack Hub 集成系统。

由于租户使用模式方面的原因,某些租户共享使用的空间比其他共享要多。 这可能会导致某些共享在其他相对用得极少的共享之前就遇到空间不足的情况。

可将某些 Blob 容器手动迁移到不同的共享,在过度使用的共享中释放空间。 可将多个较小容器迁移到单个共享,前提是该共享可以提供足够的容量来保存所有这些容器。 使用迁移操作来移动可用容器。 可用容器是不包含 VM 磁盘的容器。

迁移过程会在新的共享中合并容器的所有 Blob。

  • 如果有容器进入溢出模式并且已将 blob 放置在其他卷上,则新共享必须提供足够的容量来保存所迁移容器的所有 blob,包括溢出的 blob。

  • PowerShell cmdlet Get-AzsStorageContainer 只识别容器的初始卷上的已用空间。 此 cmdlet 不识别已溢出到其他卷的 blob 使用的空间。 因此,容器的完整大小可能不明显。 新共享中的容器整合可能会使该共享进入溢出状态,以便将数据置于其他共享。 因此,可能需要重新均衡共享。

  • 如果你缺少对特定资源组的权限,且无法使用 PowerShell 来查询溢出数据的其他卷,请配合这些资源组和容器的所有者,在迁移数据之前了解要迁移的总数据量。

重要

迁移容器的 Blob 是一项脱机操作,需要用到 PowerShell。 在迁移完成之前,要迁移的容器的所有 Blob 会保持脱机状态且不可使用。 还应该避免在所有现有迁移操作完成之前升级 Azure Stack Hub。

使用 PowerShell 迁移容器

  1. 确认已安装并配置 Azure PowerShell。 有关详细信息,请参阅使用 Azure PowerShell 管理 Azure 资源

  2. 检查容器,了解要迁移的共享中包含哪种数据。 若要识别卷中可迁移的最佳候选容器,请使用 Get-AzsStorageContainer cmdlet:

    $farm_name = (Get-AzsStorageFarm)[0].name
    $shares = Get-AzsStorageShare -FarmName $farm_name
    $containers = Get-AzsStorageContainer -ShareName $shares[0].ShareName -FarmName $farm_name
    

    然后检查 $containers:

    $containers
    

    Example: $containers

  3. 识别用于保存要迁移的容器的最佳目标共享:

    $destinationshare = ($shares | Sort-Object FreeCapacity -Descending)[0]
    

    然后检查 $destinationshares:

    $destinationshares
    

    Example: $destination shares

  4. 开始迁移容器。 迁移是异步操作。 如果在首次迁移完成之前开始迁移其他容器,请使用作业 ID 来跟踪每个容器的状态。

    $job_id = Start-AzsStorageContainerMigration -StorageAccountName $containers[0].Accountname -ContainerName $containers[0].Containername -ShareName $containers[0].Sharename -DestinationShareUncPath $destinationshares[0].UncPath -FarmName $farm_name
    

    然后检查 $jobId。 在以下示例中,请将 d62f8f7a-8b46-4f59-a8aa-5db96db4ebb0 替换为要检查的作业 ID:

    $jobId
    d62f8f7a-8b46-4f59-a8aa-5db96db4ebb0
    
  5. 使用作业 ID 检查迁移作业的状态。 容器迁移完成后,MigrationStatus 会设置为 Complete

    Get-AzsStorageContainerMigrationStatus -JobId $job_id -FarmName $farm_name
    

    Screenshot that shows the migration status.

  6. 可以取消正在进行的迁移作业。 系统会以异步方式处理已取消的迁移作业。 可以使用 $jobid 跟踪取消操作:

    Stop-AzsStorageContainerMigration -JobId $job_id -FarmName $farm_name
    

    Example: Rollback status

  7. 可以再次运行步骤 6 中的命令,直到迁移状态为 Canceled

    Screenshot that shows an example of a canceled migration status.

移动 VM 磁盘

此选项仅适用于 Azure Stack Hub 集成系统。

用于管理空间的最极端方法涉及到移动 VM 磁盘。 由于移动附加容器(包含 VM 磁盘的容器)的过程很复杂,请在 Azure 支持部门的帮助下完成此操作。

在卷间迁移托管磁盘

此选项仅适用于 Azure Stack Hub 集成系统。

由于租户使用模式方面的原因,某些租户卷使用的空间比其他卷要多。 结果可能是,某个卷在其他相对用得极少的卷之前就遇到了空间不足的情况。

可将某些托管磁盘手动迁移到其他卷,以释放过度使用的卷上的空间。 可将多个托管磁盘迁移到有足够的容量来保存它们的单个卷。 使用迁移移动脱机托管磁盘。 脱机托管磁盘是指未附加到 VM 的磁盘。

重要

迁移托管磁盘是一项脱机操作,需要用到 PowerShell。 在开始迁移作业前,必须解除分配候选磁盘的所有者 VM,或者,将候选磁盘从其所有者 VM 拆离(在迁移作业完成后,可以重新分配 VM 或重新附加磁盘)。 在迁移完成之前,要迁移的所有托管磁盘都必须保持预留或脱机状态,并且不能被使用,否则,迁移作业将中止,并且所有已取消迁移的磁盘仍保留在其原始卷上。 还应该避免在所有现有迁移操作完成之前升级 Azure Stack Hub。

使用 PowerShell 迁移托管磁盘

  1. 确认已安装并配置 Azure PowerShell。 有关配置 PowerShell 环境的说明,请参阅安装适用于 Azure Stack Hub 的 PowerShell。 若要登录到 Azure Stack Hub,请参阅配置操作员环境并登录到 Azure Stack Hub

  2. 检查托管磁盘以了解计划迁移的卷上有哪些磁盘。 若要识别卷中可迁移的最佳候选磁盘,请使用 Get-AzsDisk cmdlet:

    $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
    

    Example: $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
    

    Example: Migration status

    如果要在一个迁移作业中迁移多个托管磁盘,还可以检查作业的子任务。

    $job.Subtasks
    

    Example: Migration sub task status

  6. 可以取消正在进行的迁移作业。 系统会以异步方式处理已取消的迁移作业。 可以使用作业名称跟踪取消操作,直至状态确认迁移作业“已取消”:

    Stop-AzsDiskMigrationJob -Name $jobName
    

    Example: Canceled status

分布非托管磁盘

此选项仅适用于 Azure Stack Hub 集成系统。

用于管理空间的最极端方法涉及到移动非托管磁盘。 如果租户将多个非托管磁盘添加到一个容器,则在该容器进入溢出模式之前,该容器的总已用容量可能会超出其所在卷的可用容量。 为了避免单个容器用尽卷空间,租户可以将一个容器的现有非托管磁盘分布到其他容器。 由于分布附加容器(包含 VM 磁盘的容器)的过程很复杂,请在 Azure 支持部门的帮助下完成此操作。

可用于 VM 的内存

Azure Stack Hub 作为计算和存储的超融合群集而构建。 通过融合可以实现共享硬件(称为缩放单元)。 在 Azure Stack Hub 中,缩放单元为资源提供可用性和可伸缩性。 缩放单元由一组称为主机或节点的 Azure Stack Hub 服务器构成。 基础结构软件托管在一组 VM 中,与租户 VM 共享相同的物理服务器。 然后所有 Azure Stack Hub VM 可以通过缩放单元的 Windows Server 群集技术和独立的 Hyper-V 实例来管理。 缩放单元简化了 Azure Stack Hub 的获取和管理。 使用缩放单元还可以跨 Azure Stack Hub、租户与基础结构移动和缩放所有服务。

可以在管理门户中查看饼图,其中显示了 Azure Stack Hub 中可用和已用的内存,如下所示:

physical memory on Azure Stack Hub

以下组件消耗了饼图中的已用内存部分:

  • 主机 OS 的使用量或预留量:这是主机上的操作系统 (OS)、虚拟内存页面表、主机 OS 中运行的进程以及空间直通内存缓存使用的内存。 此值依赖于主机上运行中的不同 Hyper-V 进程使用的内存,因此可能有浮动。
  • 基础结构服务 – 这些是构成 Azure Stack Hub 的基础结构 VM。 这需要大约 31 个 VM,这些 VM 占用 242 GB + (4 GB x 节点数) 的内存。 我们一直在努力让基础结构服务变得更具可伸缩性和弹性,因此基础结构服务组件的内存用量可能会有变化。
  • 复原功能的预留量:Azure Stack Hub 预留一部分内存,用于在单个主机故障期间保持租户可用性,以及在修补和更新期间让 VM 成功进行实时迁移。
  • 租户 VM:这是 Azure Stack Hub 用户创建的 VM。 除了运行 VM 以外,任何在结构上登陆的 VM 也消耗内存。 这意味着,处于“正在创建”或“失败”状态的 VM 或者从来宾内部关闭的 VM 将消耗内存 。 但是,已在 Azure Stack Hub 用户门户、PowerShell 和 Azure CLI 中使用 stop deallocated(停止并解除分配)选项解除分配的 VM 不会消耗 Azure Stack Hub 中的内存。
  • 附加资源提供程序:为 SQL、MySQL 和应用服务等附加资源提供程序部署的 VM。

Capacity used in a blade on a four node Azure Stack Hub

可用于 VM 放置的内存

没有任何方法可供 Azure Stack Hub 云操作员用来自动检查为每个 VM 分配的内存。 你可以访问用户 VM,并手动计算分配的内存。 但是,分配的内存并不反映实际使用量。 此值可能低于分配值。

若要测算 VM 的可用内存,请使用以下公式:

VM 位置的可用内存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 = 主机 OS 使用的操作系统预留量/内存,在此公式中为 0.15

V = 缩放单元中最大的 VM(从内存消耗量看)

Azure Stack Hub 基础结构开销 = 242 GB + (4 GB x 节点数)。 这说明使用了大约 31 个 VM 来托管 Azure Stack Hub 的基础结构。

主机 OS 使用的内存 = 主机内存的 15% (0.15)。 操作系统预留值是一个估算值,因主机的物理内存容量和一般操作系统开销而异。

值 V(缩放单元中的最大 VM)根据部署的最大租户 VM 动态变化。 例如,最大 VM 值可能是 7 GB 或 112 GB,或者是 Azure Stack Hub 解决方案中任何其他受支持的 VM 内存大小。 我们在此处选取了最大 VM 的大小以预留足够的内存,这样,实时迁移此大型 VM 就不会失败。 更改 Azure Stack Hub 结构上最大的 VM 除了导致 VM 本身的内存增加以外,还会增大复原功能预留量。

例如,在包含 12 个节点的缩放单元中:

缩放单元详细信息
sts (N) 12
每个主机的内存 (H) 384
缩放单元的总内存 4608
OS 预留量 (R) 15%
最大 VM (V) 112
复原功能预留量 = H + R * ((N-1) * H) + V * (N-2)
复原功能预留量 = 2137.6

因此,根据上述信息,如果最大 VM 具有 112 GB 内存,则可以计算出,包含 12 个节点(每个主机节点具有 384 GB 内存,总共 4,608 GB 内存)的 Azure Stack 预留了 2,137 GB 内存用于复原功能。

按下面所示查看“物理内存”的“容量”边栏选项卡时,“已使用”值包括复原功能预留量 。 该图来自某个四节点 Azure Stack Hub 实例。

Capacity usage on a four node Azure Stack Hub

规划 Azure Stack Hub 的容量时,请记得这些考虑因素。 此外,可以使用 Azure Stack Hub Capacity Planner

后续步骤

若要详细了解如何向用户提供 VM,请参阅管理 Azure Stack Hub 的存储容量