本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# Amazon EBS 吞吐量优化型 HDD 和冷 HDD 卷
<a name="hdd-vols"></a>

Amazon EBS 提供的 HDD 卷分为以下几个类别：
+ 吞吐量优化型 HDD – 适用于访问频率较高的吞吐量密集型工作负载的低成本 HDD。
+ 冷 HDD – 适用于访问频率较低的工作负载的最低成本 HDD。

**Topics**
+ [

## 每实例吞吐量限制
](#throughput-limitations)
+ [

## 吞吐量优化型 HDD 卷
](#EBSVolumeTypes_st1)
+ [

## Cold HDD 卷
](#EBSVolumeTypes_sc1)
+ [

## 使用 HDD 卷时的性能注意事项
](#EBSVolumeTypes_considerations)
+ [

## 监控卷的突发存储桶余额
](#monitoring_burstbucket-hdd)

## 每实例吞吐量限制
<a name="throughput-limitations"></a>

`st1` 和 `sc1` 卷的吞吐量始终由以下限制中较小的决定：
+ 卷的吞吐量限制
+ 实例的吞吐量限制

对于所有 Amazon EBS 卷，我们建议选择适当的 EBS 优化型 EC2 实例来避免网络瓶颈。

## 吞吐量优化型 HDD 卷
<a name="EBSVolumeTypes_st1"></a>

吞吐量优化型 HDD（`st1`）卷提供低成本的磁性存储，该存储以吞吐量而不是 IOPS 定义性能。该卷类型是大型顺序工作负载（例如 Amazon EMR、ETL、数据仓库和日志处理）的理想之选。不支持可启动的 `st1` 卷。

吞吐量优化型 HDD（`st1`）卷虽然与 Cold HDD（`sc1`）卷类似，但其旨在支持*频繁*访问的数据。

**注意**  
此卷类型针对涉及大规模、连续I/O, and we recommend that customers with workloads performing small, random I/O使用[Amazon EBS 通用型 SSD 卷](general-purpose.md)或的工作负载进行了优化[Amazon EBS 预调配 IOPS SSD 卷](provisioned-iops.md)。有关更多信息，请参阅 [硬盘 read/writes 上的小容量效率低下](#inefficiency)。

附加到 EBS 优化型实例的吞吐量优化型 HDD（`st1`）卷旨在提供一致的性能，在给定年度的 99% 时间内交付至少 90% 的预期吞吐量性能。

### 吞吐量积分和突增性能
<a name="ST1ThroughputBurst"></a>

与 `gp2` 类似，`st1` 使用突增存储桶模型提高性能。卷大小决定卷的基准吞吐量，即卷积累吞吐量积分的速度。卷大小还决定卷的突增吞吐量，即有积分可用时消耗积分的速度。较大的卷有较高的基准吞吐量和突增吞吐量。您的音量拥有的积分越多，它 I/O 在爆发等级下可以行驶的时间就越长。

下图显示 `st1` 的突增存储桶行为。

![\[st1 突增存储桶\]](http://docs.aws.amazon.com/zh_cn/ebs/latest/userguide/images/st1-burst-bucket.png)


`st1` 卷的可用吞吐量受吞吐量和吞吐量积分上限的限制，由以下公式表示：

```
(Volume size) × (Credit accumulation rate per TiB) = Throughput
```

对于 1 TiB 的`st1`卷，突发吞吐量限制为 250MiB/s, the bucket fills with credits at 40 MiB/s，并且最多可以容纳 1 TiB 的积分。

体积越大，这些限制就会线性扩展，吞吐量上限为每 MiB/s. After the bucket is depleted, throughput is limited to the baseline rate of 40 MiB/s TiB 500。

对于介于 0.125 TiB 到 16 TiB 之间的卷大小，基准吞吐量从 MiB/s 5 到 500 MiB/s 不等，在 12.5 TiB 时达到上限，如下所示：

```
            40 MiB/s
12.5 TiB × ---------- = 500 MiB/s
             1 TiB
```

突发吞吐量从 31 MiB/s 到 500 MiB/s 的上限不等，上限为 2 TiB，如下所示：

```
         250 MiB/s
2 TiB × ---------- = 500 MiB/s
          1 TiB
```

下表列出了 `st1` 基准和突增吞吐量值的完整范围。


| 卷大小（TiB） | ST1 基本吞吐量 (MiB/s) | ST1 突发吞吐量 (MiB/s) | 
| --- | --- | --- | 
| 0.125 | 5 | 31 | 
| 0.5 | 20 | 125 | 
| 1 | 40 | 250 | 
| 2 | 80 | 500 | 
| 3 | 120 | 500 | 
| 4 | 160 | 500 | 
| 5 | 200 | 500 | 
| 6 | 240 | 500 | 
| 7 | 280 | 500 | 
| 8 | 320 | 500 | 
| 9 | 360 | 500 | 
| 10 | 400 | 500 | 
| 11 | 440 | 500 | 
| 12 | 480 | 500 | 
| 12.5 | 500 | 500 | 
| 13 | 500 | 500 | 
| 14 | 500 | 500 | 
| 15 | 500 | 500 | 
| 16 | 500 | 500 | 

下图绘制了表值：

![\[比较 st1 基准性能和突增性能\]](http://docs.aws.amazon.com/zh_cn/ebs/latest/userguide/images/st1_base_v_burst.png)


**注意**  
如果创建吞吐量优化型 HDD（`st1`）卷的快照，则在快照处理过程中，性能可能会降低，最坏情况下会降低到卷的基准值。

有关使用 CloudWatch 指标和警报监控突发存储桶余额的信息，请参阅[监控卷的突发存储桶余额](#monitoring_burstbucket-hdd)。

## Cold HDD 卷
<a name="EBSVolumeTypes_sc1"></a>

Cold HDD（`sc1`）卷提供低成本的磁性存储，该存储以吞吐量而不是 IOPS 定义性能。`st1` 的吞吐量限制比 `sc1` 更低，是大型顺序冷数据工作负载的绝佳选择。如果您需要频繁访问数据并且希望节约成本，`sc1` 提供价格低廉的块存储。不支持可启动的 `sc1` 卷。

Cold HDD（`sc1`）卷虽然与吞吐量优化型 HDD（`st1`）卷类似，但其旨在支持*不频繁*访问的数据。

**注意**  
此卷类型针对涉及大规模、连续I/O, and we recommend that customers with workloads performing small, random I/O使用[Amazon EBS 通用型 SSD 卷](general-purpose.md)或的工作负载进行了优化[Amazon EBS 预调配 IOPS SSD 卷](provisioned-iops.md)。有关更多信息，请参阅 [硬盘 read/writes 上的小容量效率低下](#inefficiency)。

附加到 EBS 优化型实例的 Cold HDD（`sc1`）卷旨在提供一致的性能，在给定年度的 99% 时间内交付至少 90% 的预期吞吐量性能。

### 吞吐量积分和突增性能
<a name="SC1ThroughputBurst"></a>

与 `gp2` 类似，`sc1` 使用突增存储桶模型提高性能。卷大小决定卷的基准吞吐量，即卷积累吞吐量积分的速度。卷大小还决定卷的突增吞吐量，即有积分可用时消耗积分的速度。较大的卷有较高的基准吞吐量和突增吞吐量。您的音量拥有的积分越多，它 I/O 在爆发等级下可以行驶的时间就越长。

![\[sc1 突增存储桶\]](http://docs.aws.amazon.com/zh_cn/ebs/latest/userguide/images/sc1-burst-bucket.png)


`sc1` 卷的可用吞吐量受吞吐量和吞吐量积分上限的限制，由以下公式表示：

```
(Volume size) × (Credit accumulation rate per TiB) = Throughput
```

对于 1 TiB 的`sc1`卷，突发吞吐量限制为 80MiB/s, the bucket fills with credits at 12 MiB/s，并且最多可以容纳 1 TiB 的积分。

体积越大，这些限制就会线性扩展，吞吐量上限为每 MiB/s. After the bucket is depleted, throughput is limited to the baseline rate of 12 MiB/s TiB 最大 250。

对于介于 0.125 TiB 到 16 TiB 之间的卷大小，基准吞吐量从 MiB/s 1.5 到最大 192 MiB/s 不等，在 16 TiB 时可达到，如下所示：

```
           12 MiB/s
16 TiB × ---------- = 192 MiB/s
            1 TiB
```

突发吞吐量从 10 MiB/s 到 250 MiB/s 的上限不等，上限为 3.125 TiB，如下所示：

```
             80 MiB/s
3.125 TiB × ----------- = 250 MiB/s
              1 TiB
```

下表列出了 `sc1` 基准和突增吞吐量值的完整范围：


| 卷大小（TiB） | SC1 基本吞吐量 (MiB/s) | SC1 突发吞吐量 (MiB/s) | 
| --- | --- | --- | 
| 0.125 | 1.5 | 10 | 
| 0.5 | 6 | 40 | 
| 1 | 12 | 80 | 
| 2 | 24 | 160 | 
| 3 | 36 | 240 | 
| 3.125 | 37.5 | 250 | 
| 4 | 48 | 250 | 
| 5 | 60 | 250 | 
| 6 | 72 | 250 | 
| 7 | 84 | 250 | 
| 8 | 96 | 250 | 
| 9 | 108 | 250 | 
| 10 | 120 | 250 | 
| 11 | 132 | 250 | 
| 12 | 144 | 250 | 
| 13 | 156 | 250 | 
| 14 | 168 | 250 | 
| 15 | 180 | 250 | 
| 16 | 192 | 250 | 

下图绘制了表值：

![\[比较 sc1 基准性能和突增性能\]](http://docs.aws.amazon.com/zh_cn/ebs/latest/userguide/images/sc1_base_v_burst.png)


**注意**  
如果创建 Cold HDD（`sc1`）卷的快照，则在快照处理过程中，性能可能会降低，最坏情况下会降低到卷的基准值。

有关使用 CloudWatch 指标和警报监控突发存储桶余额的信息，请参阅[监控卷的突发存储桶余额](#monitoring_burstbucket-hdd)。

## 使用 HDD 卷时的性能注意事项
<a name="EBSVolumeTypes_considerations"></a>

为了使用 HDD 卷获得最优的吞吐量结果，请根据以下注意事项计划您的工作负载。

### **比较吞吐量优化型 HDD 和 Cold HDD**
<a name="ST1vSC1"></a>

`st1` 和 `sc1` 存储桶大小因卷大小而异，满的存储桶包含充足的令牌用于完整卷扫描。不过，因为每实例和每卷的吞吐量限制，更大的 `st1` 和 `sc1` 卷需要更长的时间完成卷扫描。附加到较小实例的卷被限制在每实例吞吐量上，而不是 `st1` 或 `sc1` 吞吐量限制。

`st1` 和 `sc1` 专为在 99% 的时间内实现 90% 的突增吞吐量性能一致性而设计。不合规时间段大致均匀分布，目标是达到 99% 的每小时预计总吞吐量。

一般来说，扫描时间可由此公式表示：

```
 Volume size
------------ = Scan time
 Throughput
```

例如，考虑到性能一致性保证和其他优化，拥有 5 TiB 卷的 `st1` 客户预计在 2.91 到 3.27 小时内完成整卷扫描。
+ 最佳扫描时间

  ```
     5 TiB            5 TiB
  ----------- = ------------------ = 10,486 seconds = 2.91 hours 
   500 MiB/s     0.00047684 TiB/s
  ```
+ 最长扫描时间

  ```
    2.91 hours
  -------------- = 3.27 hours
   (0.90)(0.99) <-- From expected performance of 90% of burst 99% of the time
  ```

同样，拥有 5 TiB 卷的 `sc1` 客户预计在 5.83 到 6.54 小时内完成整卷扫描。
+ 最佳扫描时间

  ```
     5 TiB             5 TiB
  ----------- = ------------------- = 20972 seconds = 5.83 hours 
   250 MiB/s     0.000238418 TiB/s
  ```
+ 最长扫描时间

  ```
    5.83 hours
  -------------- = 6.54 hours
   (0.90)(0.99)
  ```

下表列出了不同大小卷的理想扫描时间，假设存储桶是满的并且有充足的实例吞吐量。


| 卷大小（TiB） | ST1 连拍扫描时间（小时）\$1 | SC1 连拍扫描时间（小时）\$1 | 
| --- | --- | --- | 
| 1 | 1.17 | 3.64 | 
| 2 | 1.17 | 3.64 | 
| 3 | 1.75 | 3.64 | 
| 4 | 2.33 | 4.66 | 
| 5 | 2.91 | 5.83 | 
| 6 | 3.50 | 6.99 | 
| 7 | 4.08 | 8.16 | 
| 8 | 4.66 | 9.32 | 
| 9 | 5.24 | 10.49 | 
| 10 | 5.83 | 11.65 | 
| 11 | 6.41 | 12.82 | 
| 12 | 6.99 | 13.98 | 
| 13 | 7.57 | 15.15 | 
| 14 | 8.16 | 16.31 | 
| 15 | 8.74 | 17.48 | 
| 16 | 9.32 | 18.64 | 

 \$1 这些扫描时间在执行 1 MiB 顺序 I/O 时采取平均队列深度（四舍五入到最近的整数）四或更多。

因此，如果您有面向吞吐量的工作负载需要快速完成扫描（最快 500MiB/s）或一天查询几个整卷，请使用 `st1`。如果您正在进行成本优化，您的数据访问频率相对较低，并且不需要超过 250 MiB/s 的扫描性能，则使用。`sc1`

### 硬盘 read/writes 上的小容量效率低下
<a name="inefficiency"></a>

`st1`和`sc1`卷的性能模型针对顺序进行了优化I/Os, favoring high-throughput workloads, offering acceptable performance on workloads with mixed IOPS and throughput, and discouraging workloads with small, random I/O。

例如，1 MiB 或更少的 I/O 请求算作 1 MiB 的积分。 I/O 但是，如果它们 I/Os 是连续的，则它们会合并为1 MiB的 I/O 区块，并且仅计为1 MiB积分。 I/O 

## 监控卷的突发存储桶余额
<a name="monitoring_burstbucket-hdd"></a>

您可以使用亚马逊上提供的 Amazon EBS `BurstBalance` 指标监控`st1`和`sc1`卷的突发存储桶级别。 CloudWatch此指标显示 `st1` 和 `sc1` 在突增存储桶中剩余的吞吐量积分。有关指标和其他与 I/O 相关的指标的更多信息，请参阅[Amazon EBS I/O 特征和监控](ebs-io-characteristics.md)。`BurstBalance` CloudWatch 还允许您设置警报，当该`BurstBalance`值降至一定水平时会通知您。有关更多信息，请参阅[创建 CloudWatch 警报](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)。