小编smi*_*lli的帖子

这听起来像是一个奇怪的问题，但它引起了我与一些同事的热烈讨论。考虑一个由八个或十二个磁盘组成的中等大小的 RAID 阵列。在购买第一批磁盘，或购买替换磁盘以扩大阵列或更新硬件时，可以采用两种广泛的方法：

1. 从一个供应商处一次性购买所有驱动器，并收到一个包含所有磁盘的大盒子。
2. 从各种供应商处订购一张磁盘，和/或分散（在几天或几周内）每个一张磁盘的多个订单。

显然有一些中间立场，但这些是主要的对立心态。我一直很好奇哪种方法在降低阵列灾难性故障的风险方面更明智。（让我们定义为“25% 的磁盘在等于重新同步阵列一次所需的时间窗口内发生故障。”）逻辑是，如果所有磁盘来自同一个地方，它们可能都具有相同的潜在的缺陷等待打击。如果你愿意，同样的定时炸弹与时钟上的相同初始倒计时。

我为每种方法收集了一些更常见的优缺点，但其中一些感觉像是猜测和直觉，而不是基于确凿证据的数据。

一次购买，亲们

• 在研究/订购阶段花费的时间更少。
• 如果供应商收取费用，则将运输成本降至最低。
• 几乎可以保证磁盘在其操作特性（温度、振动等）方面具有相同的固件版本和相同的“怪癖”。
• 价格上涨/库存短缺不太可能使项目中途停滞。
• 每个下一张磁盘在需要安装的那一刻就在手边。
• 序列号都是预先知道的，磁盘可以按序列号递增的顺序安装在机箱中。看起来过于挑剔，但有些人似乎很重视这一点。（我猜他们的管理界面按序列号而不是硬件端口顺序对磁盘进行排序......？）

一次购买，缺点

• 所有磁盘（可能）都来自同一家工厂，同时制造，材料相同。它们储存在相同的环境中，并在运输过程中遭受相同的潜在滥用。存在于一个中的任何缺陷或损坏都可能存在于所有中。
• 如果一次将驱动器更换到现有阵列中，并且每个新磁盘都需要单独重新同步，则可能需要几周时间才能安装订单中的最后一个磁盘并发现故障。与供应商的退货/换货窗口可能会在此期间到期。
• 无法利用项目期间可能发生的近期价格下跌。

单独购买，优点

• 如果一个磁盘出现故障，它与任何其他磁盘共享很少的制造/运输历史。如果故障是由制造或运输过程中的某些原因引起的，那么根本原因很可能不会发生在任何其他磁盘上。
• 如果磁盘在到达时已损坏或在使用的最初几个小时内出现故障，则会在货物到达后不久检测到，并且退货过程可能会更加顺利。

单独购买，缺点

• 需要花费大量时间才能找到足够多且价格合理的供应商。订单跟踪、交付失败、损坏的物品退货和其他问题可能需要很长时间才能解决。
• 运输成本可能更高。
• 一个非常现实的可能性是需要一个新磁盘，但手头没有磁盘，从而使项目停滞。
• 想象的好处。无论供应商或购买日期如何，所有磁盘都来自同一个地方并且实际上是相同的。制造缺陷会被质量控制检测到，不合格的磁盘不会被出售。运输损坏必须非常严重（并且肉眼清晰可见），以至于打开包装时损坏的驱动器会很明显。

如果我们仅按要点计数，“批量购买”显然会获胜。但是一些优点很弱，而一些缺点很强。许多要点只是简单地说明了其他一些要点的逻辑逆。其中一些事情可能是荒谬的迷信。但是，如果迷信在维护阵列完整性方面做得更好，我想我会愿意接受它。

哪一组在这里最明智？

更新：我有与此讨论相关的数据。我个人构建的最后一个阵列（大约四年前）有八个磁盘。我从一个供应商处订购，但将购买分成两个订单，每个订单四个磁盘，相隔大约一个月。阵列的一个磁盘在运行的最初几个小时内发生故障。它来自第一批，并且该订单的退货窗口在所有东西都旋转起来的时间内已经关闭。

四年后，七个原始磁盘加上一个替换磁盘仍然没有错误地运行。（敲木头。）

假设我有一个带有私有接口和公共接口的服务器。公共可能有 HTTP(S) 服务器之类的东西，私有可能有 MySQL 和 SSH。

显然 Nagios 可用于检查服务是否在其各自的接口上运行。但是，构建明确测试 MySQL 和 SSH 端口未在公共接口上打开的检查是个好主意吗？这个想法是捕捉无意的错误配置，这些错误配置已经打开了应该是私有的服务，并适当地发出警报。

我的一部分认为这不会很好地扩展 - 想象一下有一个 iptables DROP 规则，例如，检查必须等到超过检查超时才能完成并继续。但是该超时时间必须足够长，以便能够将被阻止的服务与真正陷入困境的开放服务区分开来。

这是一个实用的想法吗？Nagios 是正确的工具吗？我什至没有研究过否定 TCP 检查插件结果的可行性，但我确定这是可行的......

我在 Puppet 模块中有一个步骤，它大致执行以下操作来设置一些应用程序密钥：

file { '/root/setup_app_keys.sh':
  ensure => file,
  owner  => 'root',
  group  => 'root',
  mode   => '0700',
  source => 'puppet:///modules/app_module/setup_app_keys.sh',
}

exec { 'setup_app_keys':
  unless  => '/etc/pki/tls/private/app-foo.key',
  command => '/root/setup_app_keys.sh',
  user    => 'root',
  group   => 'root',
}

该setup_app_keys.sh脚本有点太长，无法制作成（可读的）单行，所以我将它保存到机器的文件系统并从那里执行它。它在其中创建文件/etc/pki...并且运行良好。

令人讨厌的是，shell 脚本基本上是一次性使用的东西。它不应该在机器的生命周期内再次运行，但它必须留在 Puppet 存储它的文件系统上。如果它被删除，Puppet 会帮助重新创建它。

我认为必须有一种方法可以使用exec专门重写它，这将允许我在需要时从 puppetmaster 下载脚本，执行一次，然后丢弃脚本（或不首先存储它）。但我尝试过的一切都是这样的：

command => 'puppet:///modules/app_module/setup_app_keys.sh',

或者

command => 'curl http://__[various puppetmaster URLs]__ | sh',

并且这两种方法似乎都不起作用。是我要求太多，还是这种方法有缺陷？

我很久以前就了解到，如果您希望 EC2 实例能够与 AWS 服务（如 SQS、Kinesis 等）通信，则该实例必须具有公共 IP 地址，或者需要在 VPC 中进行 NAT .

今年早些时候我第一次听说VPC Endpoints 时，它似乎改变了游戏规则——一种从只有私有 IP 的实例访问这些服务的方法。但唯一受支持的服务是 S3 的事实似乎非常有限。我目前管理的每个 EC2 实例都依赖于非 S3 AWS 资源，这些资源需要流量通过公共 IP 流出。

我很好奇将 VPC 端点用于 S3 是否还有任何其他好处，我知道堆栈的其余部分仍将依赖公共 IP，并且会持续一段时间。速度/吞吐量是否有任何可衡量的改进，或任何其他可以超过管理开销的好处？