节点主机将访问网络来安装任何 RPM 依赖项，如 atomic-openshift-*、iptables 和 CRI-O 或 Docker。预安装这些依赖关系，创建更高效的安装，因为仅在需要时访问 RPM，而不是在安装过程中每个主机执行多次。

对于无法访问 registry 以进行安全目的的计算机也很有用。

OpenShift Container Platform 安装方法使用 Ansible。Ansible 对于运行并行操作非常有用，这意味着快速高效的安装。但是，这些可通过额外的调整选项加以改进。如需可用 Ansible 配置选项列表，请参阅 Configuring Ansible 部分。

从最低延迟控制节点（LAN 速度）运行安装程序。不建议在广域网络(WAN)上运行，因此不会因为丢失的网络连接运行安装。

Ansible 为 性能和扩展提供了自己的指导，包括使用 RHEL 6.6 或更高版本来确保 OpenSSH 支持 ControlPersist 的版本，并从与集群相同的 LAN 中运行安装程序，但不 从集群中的机器运行。

以下是用于大型集群安装和管理的 Ansible 示例，其中包含了 Ansible 记录的推荐：

# cat /etc/ansible/ansible.cfg

# config file for ansible -- http://ansible.com/
# ==============================================
[defaults]
forks = 20 1
host_key_checking = False
remote_user = root
roles_path = roles/
gathering = smart
fact_caching = jsonfile
fact_caching_connection = $HOME/ansible/facts
fact_caching_timeout = 600
log_path = $HOME/ansible.log
nocows = 1
callback_whitelist = profile_tasks

[privilege_escalation]
become = False

[ssh_connection]
ssh_args = -o ControlMaster=auto -o ControlPersist=600s -o ServerAliveInterval=60
control_path = %(directory)s/%%h-%%r
pipelining = True 2
timeout = 10

在安装后可能会更改网络子网，但难度比较困难。安装前可以更容易地考虑网络子网大小，因为尽可能提高大小可能会给增长的集群造成问题。

有关推荐的网络子网实践，请参阅网络优化主题。

除了 pod 流量外，OpenShift Container Platform 基础架构中最常用的数据路径也介于 OpenShift Container Platform master 主机和 etcd 之间。OpenShift Container Platform API 服务器（master 二进制的一部分）在节点状态、网络配置、secret 等方面咨询 etcd。

通过以下方法优化此流量路径：

OpenShift Container Platform master 会积极缓存资源的反序列化版本，以简化 CPU 负载。但是，如果较小的 pod 集群小于 1000 个 pod，这个缓存可能会浪费大量内存用于微小的 CPU 负载。默认缓存大小为 50,000 个条目，它根据资源的大小，可以将 cupy 1 增加到 2 GB 内存。使用 /etc/origin/master/master-config.yaml 中的以下设置可以减少这个缓存大小：

kubernetesMasterConfig:
  apiServerArguments:
    deserialization-cache-size:
    - "1000"

发送到 API 服务器的客户端请求或 API 调用数量由每秒的 Queries(QPS)值和 API 服务器处理的并发请求数决定。客户端可能会过量 QPS 速率发出的请求数量取决于突发值，这对具有极限的应用程序来说非常有用，并可执行不监管的请求数量。当 API 服务器处理大量并发请求时，对请求的响应时间，特别是大型和/或高密度的集群。建议您监控 Prometheus 中的 apiserver_request_count 速率指标，并相应地调整 maxRequestsInFlight 和 QPS。

更改默认值时，需要有一个很好的平衡，因为 API 服务器的 CPU 和内存消耗，etcd IOPS 会在并行处理更多请求时增加。另请注意，大量非watch 请求可能会在固定 60 秒超时后取消 API 服务器过载，客户端开始重试。

API 服务器系统中提供了足够的 CPU 和内存资源，API 服务器请求过载问题可安全地缓解这个问题。通过考虑以上提到的因素并浏览了 maxRequestsInFlight、API qps 和 burst 值 *_/etc/origin/master/master-config.yaml

masterClients:
  openshiftLoopbackClientConnectionOverrides:
    burst: 600
    qps: 300
servingInfo:
  maxRequestsInFlight: 500

OpenShift Container Platform 节点配置文件包含重要的选项，如 iptables 同步周期、SDN 网络的最大传输单元(MTU)和 proxy-mode。要配置节点，请修改适当的节点配置映射。

节点配置文件允许您将参数传递给 kubelet（节点）过程。您可以通过运行 kubelet --help 来查看可能的选项列表。

在 /etc/origin/node/node-config.yaml 文件中，两个参数控制可以调度到节点的 pod 的最大数量：pod-per-core 和 max-pods。当两个选项都被使用时，这两个选项中的较小的限制为节点上的 pod 数量。超过这些值可导致：

pods-per-core 根据节点上的处理器内核数来设置节点可运行的 pod 数量。例如，如果将一个有 4 个处理器内核的节点上的 pod-per-core 设置为 10，则该节点上允许的最大 pod 数量为 40。

kubeletArguments:
  pods-per-core:
    - "10"

max-pods 把节点可以运行的 pod 数量设置为一个固定值，而不需要考虑节点的属性。集群限制 记录 max-pods 的最大支持值。

kubeletArguments:
  max-pods:
    - "250"

使用上例时，pod-per-core 的默认值为 10，max-pods 的默认值为 250。这意味着，除非节点有 25 个或更多内核，否则 pod-per-core 默认是限制因素。

如需了解 OpenShift Container Platform 集群的建议限制，请参阅安装文档中的 大小注意事项 部分。OpenShift Container Platform 和容器引擎协调容器状态更新的建议大小帐户。这种协调会对主机和容器引擎进程造成 CPU 压力，这些压力可包括编写大量日志数据。

kubelet 与 API 服务器进行交互的频率取决于 qps 和 burst 值。如果每个节点上运行的 pod 有限，默认值就足够了。如果节点上有足够 CPU 和内存资源，可以在 /etc/origin/node/node-config.yaml 文件中调整 qps 和 burst 值：

kubeletArguments:
  kube-api-qps:
  - "20"
  kube-api-burst:
  - "40"

etcd 是一个分布式键值存储，OpenShift Container Platform 用于配置它。

etcd 3.x 引入了重要的可伸缩性和性能改进，用于减少任意大小集群的 CPU、内存、网络和磁盘要求。etcd 3.x 还会实施后向兼容的存储 API，促进磁盘 etcd 数据库的两个步骤迁移。出于迁移目的，OpenShift Container Platform 3.5 中 etcd 3.x 使用的存储模式保留在 v2 模式中。自 OpenShift Container Platform 3.6 起，新安装使用存储模式 v3。从以前的 OpenShift Container Platform 版本升级不会自动将数据从 v2 迁移到 v3。您必须使用提供的 playbook，并遵循记录的流程来迁移数据。

etcd 版本 3 实现了向后兼容的存储 API，有助于对磁盘 etcd 数据库进行两步迁移。出于迁移目的，OpenShift Container Platform 3.5 中 etcd 3.x 使用的存储模式保留在 v2 模式中。自 OpenShift Container Platform 3.6 起，新安装使用存储模式 v3。作为升级到 OpenShift Container Platform 3.7 的过程的一部分，如果需要，您需要将 etcd 存储 API 升级到 v3。在版本 3.7 及更新的版本中，必须使用 v3 API。

除了更改 v3 的新安装模式外，OpenShift Container Platform 3.6 也会开始对所有 OpenShift Container Platform 类型进行 enforcing 仲裁读取。这是为了确保对 etcd 的查询不会返回过时的数据。在单节点 etcd 集群中，过时的数据不是问题。在高可用的 etcd 部署中，通常在生产集群中找到，仲裁读取确保有效的查询结果。在数据库术语中，仲裁读是 线性的 - 每个客户端都会看到集群的最新更新状态，所有客户端会看到相同的读写序列。有关性能改进的更多信息，请参阅 etcd 3.1 公告。

请注意，OpenShift Container Platform 使用 etcd 来存储 Kubernetes 本身所需的其他信息。例如，OpenShift Container Platform 在 etcd 中存储有关镜像、构建和其他组件的信息，如 OpenShift Container Platform 在 Kubernetes 之上添加的功能需要。最后，这意味着 etcd 主机性能和大小调整的信息将与 Kubernetes 和其他建议有所不同。红帽使用 OpenShift Container Platform 用例和参数测试 etcd 可扩展性和性能，以生成最准确的建议。

使用 cluster-loader 实用程序使用 300 个节点 OpenShift Container Platform 3.6 集群来量化性能。etcd 3.x（存储模式 v2）与 etcd 3.x（存储模式 v3）的比较，会在下面的图表中识别出清晰的信息。

在负载下显著降低存储 IOPS：

稳定状态的存储 IOPS 也显著降低：

查看相同的 I/O 数据，在两个模式中绘制平均 IOPS：

API 服务器(master)和 etcd 进程的 CPU 使用率会减少：

API 服务器(master)和 etcd 进程的内存使用率也会减少：

查看 etcd 3.1 的 3 节点集群（使用存储 v3 模式和仲裁读取强制）执行的大小 I/O 操作，如下所示：

和写入：

tuned 是 Red Hat Enterprise Linux(RHEL)和其他红帽产品默认启用的调优配置文件交付机制。tuned 自定义 Linux 设置，如 sysctl、电源管理和内核命令行参数，以针对不同的工作负载性能和可扩展性要求优化操作系统。

OpenShift Container Platform 利用 tuned 守护进程，包括名为 openshift、openshift-node 和 openshift-control-plane 的 Tuned 配置集。这些配置集可以安全地增加内核中存在的一些垂直扩展限制，并在安装过程中自动应用到您的系统。

Tuned 配置集支持在配置集间继承。它们也支持一个自动扩展功能，它根据虚拟环境中是否使用了配置集来选择父配置集。openshift 配置集使用这些功能，它是 openshift-node 和 openshift-control-plane 配置集的父项。它包含与 OpenShift Container Platform 应用程序节点和 control plane 节点相关的调整。openshift-node 和 openshift-control-plane 配置集分别在 application 和 control plane 节点上设置。

将 openshift 配置集用作父级的配置集层次结构可确保传送到 OpenShift Container Platform 系统的调优是裸机主机的 throughput-performance （RHEL 默认）和适用于 RHEL Atomic 主机节点的 virtual-guest，以及适用于 RHEL Atomic Host 节点的 atomic-guest。

要查看在您的系统中启用了哪个 Tuned 配置集，请运行：

# tuned-adm active

Current active profile: openshift-node

有关 Tuned 的详情，请查看 Red Hat Enterprise Linux 性能调优指南。

您可以使用过量使用过程，以便 CPU 和内存等资源可以被需要它们的集群部分访问。

请注意，当您过量使用时，另一个应用程序可能无权访问需要的资源，从而降低了性能。但是，这可能是因为密度增加和降低成本而是一个可接受的权衡。例如，开发、质量保证(QA)或测试环境可能被过量使用，而生产环境可能并非如此。

OpenShift Container Platform 通过计算资源模型和配额系统实施资源管理。如需有关 OpenShift 资源模型 的更多信息，请参阅文档。

有关过量使用的更多信息和策略，请参阅集群管理指南中的过量使用文档。

红帽分发 rhel-tools 容器镜像，打包工具有助于调试扩展或性能问题。此容器镜像：

使用以下命令使用 rhel-tools 容器：

# atomic run rhel7/rhel-tools

如需更多信息，请参阅 RHEL 工具容器文档。

通过用于安装和管理 OpenShift Container Platform 集群的 基于 Ansible 的工具提供了额外的诊断健康检查。它们可以为当前 OpenShift Container Platform 安装报告常见部署问题。

这些检查可以使用 ansible-playbook 命令（集群安装中使用的相同方法）或作为 openshift-ansible 的容器化版本来运行。对于 ansible-playbook 方法，检查由 openshift-ansible RPM 软件包提供。对于容器化方法，openshift3/ose-ansible 容器镜像通过 Red Hat Container Registry 分发。

如需有关可用健康检查和示例用法的信息，请参阅集群管理指南中的 基于 Ansible 的健康检查。

优化存储有助于最小化所有资源中的存储使用。通过优化存储，管理员可帮助确保现有存储资源以高效的方式工作。

下表列出了 OpenShift Container Platform 可用的持久性存储技术。

您可以使用聚合模式 GlusterFS（超融合或集群托管存储解决方案）或 GlusterFS（外部托管的存储解决方案）用于 OpenShift Container Platform registry、日志记录和监控的对象存储。

下表总结了为给定的 OpenShift Container Platform 集群应用程序推荐的可配置存储技术。

容器运行时将镜像和容器存储在图形驱动程序中（可插拔式存储技术），如 DeviceMapper 和 OverlayFS。它们都有各自的优缺点。

有关 OverlayFS 的详情请参考 Red Hat Enterprise Linux(RHEL)7 发行注记。

为了提高性能，红帽建议在设备映射器中使用 overlayFS 存储驱动程序。但是，如果您已在生产环境中使用设备映射器，红帽强烈建议您对容器镜像和容器根文件系统使用精简配置。否则，始终将 overlayfs2 用于 Docker 引擎，或将 overlayFS 用于 CRI-O。

使用循环设备可能会影响性能。虽然您仍可以继续使用它，但会记录以下警告信息：

devmapper: Usage of loopback devices is strongly discouraged for production use.
Please use `--storage-opt dm.thinpooldev` or use `man docker` to refer to
dm.thinpooldev section.

要简化存储配置，请使用 docker-storage-setup 工具，它可以自动完成大部分配置详情：

对于 Overlay

对于 Thinpool

默认情况下，精简池配置为使用基础块设备的 40%。当您使用存储时，LVM 会自动将精简池扩展到 100%。这就是为什么 Data Space Total 值与基础 LVM 设备的大小不匹配。

在开发中，红帽分发中的 docker 默认为环回挂载的稀疏文件。查看您的系统是否使用回环模式：

# docker info|grep loop0

 Data file: /dev/loop0

Pod 将临时存储用于其内部操作，如保存临时文件。此临时存储的生命周期不会超过每个 pod 的生命周期，且此临时存储无法在 pod 间共享。

在 OpenShift Container Platform 3.10 之前，临时本地存储通过容器的可写层、日志目录和 EmptyDir 卷公开给 pod。与缺少本地存储相关的问题包括：

临时存储仍以同样的方式公开给 pod，但有新方法在临时存储消耗的 pod 上实施请求和限制。

务必要了解，临时存储在系统中的所有 pod 中共享，而且 OpenShift Container Platform 不提供任何级别的服务保证在管理员和用户建立的请求和限值之外。例如，临时存储不提供任何吞吐量、每秒 I/O 操作或存储性能的其他测量结果。

节点的本地存储可分为主分区和从属分区。主分区是唯一可用于临时本地存储的主分区。有两个支持的主分区，即 root 和 runtime。

OpenShift SDN 使用 OpenvSwitch、虚拟可扩展 LAN(VXLAN)隧道、OpenFlow 规则和 iptables。这个网络可以通过使用 jumbo 帧、网络接口卡（NIC）offload、多队列和 ethtool 设置来调整。

VXLAN 提供通过 VLAN 的好处，比如网络从 4096 增加到一千六百万，以及跨物理网络的第 2 层连接。这允许服务后的所有 pod 相互通信，即使它们在不同系统中运行也是如此。

VXLAN 在用户数据报协议（UDP）数据包中封装所有隧道流量。但是，这会导致 CPU 使用率增加。这些外部数据包和内数据包集都遵循常规的校验规则，以保证在传输过程中不会损坏数据。根据 CPU 性能，这种额外的处理开销可能会降低吞吐量，与传统的非覆盖网络相比会增加延迟。

云、虚拟机和裸机 CPU 性能可以处理很多 Gbps 网络吞吐量。当使用高带宽链接（如 10 或 40 Gbps）时，性能可能会降低。基于 VXLAN 的环境里存在一个已知问题，它并不适用于容器或 OpenShift Container Platform。由于 VXLAN 的实现，任何依赖于 VXLAN 隧道的网络都会有相似的性能。

如果您希望超过 Gbps，可以：

VXLAN-offload 不会降低延迟。但是，即使延迟测试也会降低 CPU 使用率。

networkConfig:
  mtu: 1450 1
  networkPluginName: "redhat/openshift-ovs-subnet" 2

OpenShift Container Platform 为 pod 和服务提供 IP 地址管理。允许使用的默认值：

在大多数情形中，部署之后无法更改这些网络。因此，规划增长非常重要。

在 配置 SDN 文档中对网络重新定义大小的限制。

要计划较大的环境，可以考虑将下列值添加到 Ansible 清单文件中的 [OSE3:vars] 部分：

[OSE3:vars]
osm_cluster_network_cidr=10.128.0.0/10

这将允许 8192 个节点，每个节点有 510 可用 IP 地址。

如需了解您要安装的软件版本，请参阅 OpenShift Container Platform 文档中的对节点/pod 中的支持性限制。

因为加密和解密节点主机使用 CPU 电源，所以启用加密时，无论使用的 IP 安全系统是什么，性能都会影响节点上的吞吐量和 CPU 使用量。

IPsec 在到达 NIC 前，会在 IP 有效负载级别加密流量，以保护用于 NIC 卸载的字段。这意味着，在启用 IPSec 时，一些 NIC 加速功能可能无法使用，并可能导致吞吐量降低并增加 CPU 用量。

OpenShift Container Platform 会公开指标，这些指标数据可由 Heapster 收集并存储在后端。作为 OpenShift Container Platform 管理员，您可以查看一个用户界面中的容器和组件指标。pod 横向自动扩展 也会使用这些指标来确定何时和如何扩展。

本节提供了扩展指标数据组件的信息。

如果测试中使用了 210 和 990 OpenShift Container Platform 节点，其中 10500 个 pod 和 11000 个 pod 分别被监控，Cassandra 数据库会在下表中所示的速度增长：

在上个计算中，预计大小大约有 20% 增加了开销，以确保存储要求不会超过计算的值。

如果 METRICS_DURATION 和 METRICS_RESOLUTION 值保持在默认值（7 天和 15 秒），则安全地规划星期的 Cassandra 存储要求。

一组指标 pod(Cassandra/Hawkular/Heapster)能够监控至少 25,000 个 pod。

# oc scale -n openshift-infra --replicas=2 rc hawkular-metrics

OpenShift Container Platform 会公开可由 cluster-monitoring-operator 收集并存储在后端的指标。作为 OpenShift Container Platform 管理员，您可以在一个 dashboard 接口（grafana）中查看系统资源、容器和组件指标。

本节提供有关扩展集群监控操作器的信息。

如果要将 Prometheus 与持久性存储搭配使用，您必须将 Ansible 清单文件中的 openshift_cluster_monitoring_operator_prometheus_storage_enabled 变量设置为 true。

对不同的扩展大小执行各种测试。Prometheus 数据库会增加，如下表中所示。

在上个计算中，预计大小大约有 20% 增加了开销，以确保存储要求不会超过计算的值。

以上计算是为默认的 OpenShift Container Platform cluster-monitoring-operator 开发的。为实现更高的扩展，编辑 Ansible 清单文件中的 openshift_cluster_monitoring_operator_prometheus_storage_capacity 变量，默认值为 50Gi。

195 GB (space per 15 days ) * 2 (pods) = 390 GB free

基础架构即服务：OpenStack

在规划环境时，请确定每个节点应该有多少个 pod:

Maximum Pods per Cluster / Expected Pods per Node = Total Number of Nodes

在某个节点中运行的 pod 数量取决于应用程序本身。考虑应用程序的内存、CPU 和存储要求。

2200 / 250 = 8.8

如果将节点数量增加到 20，那么 pod 的分布情况将变为每个节点有 110 个 pod：

2200 / 20 = 110

考虑应用程序环境示例：

推断的要求: 550 个 CPU 内核、450GB RAM 和 1.4TB 存储。

根据您的具体情况，节点的实例大小可以被增大或降低。在节点上通常会使用资源过度分配。在这个部署场景中，您可以选择运行多个额外的较小节点，或数量更少的较大节点来提供同样数量的资源。在做出决定前应考虑一些因素，如操作的灵活性以及每个实例的成本。

有些应用程序很适合于 过度分配 的环境，有些应用程序则不同。大多数 Java 应用程序以及使用巨页的应用程序都不允许使用过度分配功能。它们的内存不能用于其他应用程序。在上面的例子中，环境大约会出现 30％ 过度分配的情况，这是一个常见的比例。

Cluster Loader 是一个将大量对象部署到集群的工具程序，它可创建用户定义的集群对象。构建、配置并运行 Cluster Loader 以测量处于各种集群状态的 OpenShift Container Platform 部署的性能指标。

Cluster Loader 包含在 atomic-openshift-tests 软件包中。要安装它，请运行：

$ yum install atomic-openshift-tests

安装后，测试可执行文件 extended.test 位于 /usr/libexec/atomic-openshift/extended.test 中。

创建多个命名空间（项目），其中包含多个模板或 pod。

在 config/ 子目录中找到 Cluster Loader 的配置文件。这些配置示例中引用的 pod 文件和模板文件可在 content/ 子目录中找到。

provider: local 1
ClusterLoader:
  cleanup: true
  projects:
    - num: 1
      basename: clusterloader-cakephp-mysql
      tuning: default
      ifexists: reuse
      templates:
        - num: 1
          file: ./examples/quickstarts/cakephp-mysql.json

    - num: 1
      basename: clusterloader-dancer-mysql
      tuning: default
      ifexists: reuse
      templates:
        - num: 1
          file: ./examples/quickstarts/dancer-mysql.json

    - num: 1
      basename: clusterloader-django-postgresql
      tuning: default
      ifexists: reuse
      templates:
        - num: 1
          file: ./examples/quickstarts/django-postgresql.json

    - num: 1
      basename: clusterloader-nodejs-mongodb
      tuning: default
      ifexists: reuse
      templates:
        - num: 1
          file: ./examples/quickstarts/nodejs-mongodb.json

    - num: 1
      basename: clusterloader-rails-postgresql
      tuning: default
      templates:
        - num: 1
          file: ./examples/quickstarts/rails-postgresql.json

  tuningsets: 2
    - name: default
      pods:
        stepping: 3
          stepsize: 5
          pause: 0 s
        rate_limit: 4
          delay: 0 ms

如果用户模板中没有定义 IDENTIFIER 参数，则模板创建失败，错误信息为：error: unknown parameter name "IDENTIFIER"。如果部署模板，在模板中添加这个参数以避免出现这个错误：

{
  "name": "IDENTIFIER",
  "description": "Number to append to the name of resources",
  "value": "1"
}

如果部署 pod，则不需要添加该参数。

CPU Manager 管理 CPU 组并限制特定 CPU 的负载。

CPU Manager 对于有以下属性的负载有用：

设置 CPU Manager：

内存在块（称为页）中进行管理。在大多数系统中，页的大小为 4Ki。1Mi 内存相当于 256 个页，1Gi 内存为 262,144 页等。CPU 有内置的内存管理单元，可在硬件中管理这些页的列表。Translation Lookaside Buffer (TLB) 是虚拟页到物理页映射的小型硬件缓存。如果在硬件指令中包括的虚拟地址可以在 TLB 中找到，则其映射信息可以被快速获得。如果没有包括在 TLN 中，则称为 TLB miss。系统将会使用基于软件的，速度较慢的地址转换机制，从而出现性能降低的问题。因为 TLB 的大小是固定的，因此降低 TLB miss 的唯一方法是增加页的大小。

巨页指一个大于 4Ki 的内存页。在 x86_64 构架中，有两个常见的巨页大小: 2Mi 和 1Gi。在其它构架上的大小会有所不同。要使用巨页，必须写相应的代码以便应用程序了解它们。Transparent Huge Pages（THP）试图在应用程序不需要了解的情况下自动管理巨页，但这个技术有一定的限制。特别是，它的页大小会被限为 2Mi。当有较高的内存使用率时，THP 可能会导致节点性能下降，或出现大量内存碎片（因为 THP 的碎片处理）导致内存页被锁定。因此，有些应用程序可能更适用于（或推荐）使用预先分配的巨页，而不是 THP。

在 OpenShift Container Platform 中，pod 中的应用程序可以分配并消耗预先分配的巨页。本主题介绍了如何进行。

巨页可以使用名为 hugepages-<size> 的容器一级的资源需求被消耗。其中 size 是特定节点上支持的整数值的最精简的二进制标记。例如，如果节点支持 2048KiB 页面大小，它将提供一个可调度的资源 hugepages-2Mi。与 CPU 或内存不同，巨页不支持过量使用。

kind: Pod
metadata:
  generateName: hugepages-volume-
spec:
  containers:
  - securityContext:
      privileged: true
    image: rhel7:latest
    command:
    - sleep
    - inf
    name: example
    volumeMounts:
    - mountPath: /hugepages
      name: hugepage
    resources:
      limits:
        hugepages-2Mi: 100Mi 1
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages

有些平台支持多个巨页大小。要分配指定大小的巨页，在巨页引导命令参数前使用巨页大小选择参数hugepagesz=<size>。<size> 的值必须以字节为单位，并可以使用一个可选的后缀 [kKmMgG]。默认的巨页大小可使用 default_hugepagesz=<size> 引导参数定义。如需更多信息，请参阅配置透明巨页。

巨页面请求必须等于限制。如果指定了限制，则它是默认的，但请求不是。

巨页在 pod 范围内被隔离。容器隔离功能计划在以后的版本中推出。

后端为巨页的 EmptyDir 卷不能消耗大于 pod 请求的巨页内存。

通过带有 SHM_HUGETLB 的 shmget() 来使用巨页的应用程序，需要运行一个匹配 proc/sys/vm/hugetlb_shm_group 的 supplemental 组。

当您将聚合模式用于应用程序时，请遵循本主题中提供的指导和最佳实践，以便您可以根据工作负载类型在 gluster-block 和 GlusterFS 模式之间进行明智选择。

在 OpenShift Container Platform 3.10 中，使用这些 (no)SQL 数据库进行了大量测试：

这些数据库的存储源自聚合模式存储集群。

用于 Postgresql SQL 基准测试 pgbench，用于数据库基准测试。对于 MongoDB noSQL 基准测试 YCSB Yahoo!Cloud Serving Benchmark 用于基准测试，workloada,workloadb,workloadf 被测试

如上所述，GlusterFS 的性能转换器已经是附带最新聚合模式镜像的数据库配置集的一部分。

对于 Postgresql SQL 数据库，GlusterFS 和 gluster-block 会显示大约相同的性能结果。对于 MongoDB noSQL 数据库，gluster-block 更好地执行。因此，对 MongoDB noSQL 数据库使用基于 gluster-block 的存储。