mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-26 21:30:55 +08:00
63 lines
7.1 KiB
Markdown
63 lines
7.1 KiB
Markdown
用 NTP 把控时间（一）：使用概览
|
||
============================================================
|
||
|
||
|
||
|
||
这系列共三部分，首先，Chirs Binnie 探讨了在一个合理的架构中 NTP 服务的重要性。
|
||
|
||
鲜有互联网上的服务能如时间服务一样重要。影响你系统计时的小问题可能需要一两天才能被发现，而这些不期而遇的问题所带来的连锁反应几乎总是让人伤脑筋的。
|
||
|
||
设想你的备份服务器与网络时间协议（NTP）服务器断开连接，过了几天，引起了几小时的时间偏差。你的同事照常九点上班，发现需要大量带宽的备份服务器消耗了所有网络资源，这也就意味着他们在备份完成之前几乎不能登录工作台开始他们的日常工作。
|
||
|
||
这系列共三部分，首先，我将提供简要介绍 NTP 来防止这种困境的发生。从邮件的时间戳到记录你工作的进展，NTP 服务对于一个合理的架构是如此的重要。
|
||
|
||
可以把如此重要的 NTP 服务器（其他的服务器从此获取时钟数据）看做是倒置金字塔的底部，它被称之为<ruby>一层<rt>Stratum 1</rt></ruby>服务器（也被称为“<ruby>主<rt>primary</rt></ruby>”服务器）。这些服务器与国家级时间服务（称为<ruby>零层<rt>Stratum 0</rt></ruby>，通常这些设备是是原子钟和 GPS 钟之类的装置）直接交互。与之安全通讯的方法很多，例如通过卫星或者无线电。
|
||
|
||
令人惊讶的是，几乎所有的大型企业都会连接<ruby>二层<rt>Stratum 2</rt></ruby>服务器（或“<ruby>次级<rt>secondary</rt></ruby>”服务器）而是不是主服务器。如你所料，二层服务器和一层直接同步。如果你觉得大公司可能有自己的本地 NTP 服务器（至少两个，通常三个，为了灾难恢复之用），这些就是三层服务器。这样，三层服务器将连接上层预定义的次级服务器，负责任地传递时间给客户端和服务器，精确地反馈当前时间。
|
||
|
||
由简单设计而构成的 NTP 可以工作的前提是——多亏了通过互联网跨越了大范围的地理距离——在确认时间完全准确之前，来回时间（包什么时候发出和多少秒后被收到）都会被清楚记录。设置电脑的时间的背后要比你想象的复杂得多，如果你不相信，那[这神奇的网页][3]值得一看。
|
||
|
||
再次重提一遍，为了确保你的架构如预期般工作，NTP 是如此的关键，你的 NTP 与层次服务器之间的连接必须是完全可信赖并且能提供额外的冗余，才能保持你的内部时钟同步。在 [NTP 主站][4]有一个有用的一层服务器列表。
|
||
|
||
正如你在列表所见，一些 NTP 一层服务器以 “ClosedAccount” 状态运行；这些服务器需要事先接受才可以使用。但是只要你完全按照他们的使用引导做，“OpenAccess” 服务器是可以用于轮询使用的。而 “RestrictedAccess” 服务器有时候会因为大量客户端访问或者轮询间隙太小而受限。另外有时候也有一些专供某种类型的组织使用，例如学术界。
|
||
|
||
### 尊重我的权威
|
||
|
||
在公共 NTP 服务器上，你可能发现遵从某些规则的使用规范。现在让我们看看其中一些。
|
||
|
||
“iburst” 选项作用是如果在一个标准的轮询间隔内没有应答，客户端会发送一定数量的包（八个包而不是通常的一个）给 NTP 服务器。如果在短时间内呼叫 NTP 服务器几次，没有出现可辨识的应答，那么本地时间将不会变化。
|
||
|
||
不像 “iburst” ，按照 NTP 服务器的通用规则， “burst” 选项一般不允许使用（所以不要用它！）。这个选项不仅在轮询间隔发送大量包（明显又是八个），而且也会在服务器能正常使用时这样做。如果你在高层服务器持续发送包，甚至是它们在正常应答时，你可能会因为使用 “burst” 选项而被拉黑。
|
||
|
||
显然，你连接服务器的频率造成了它的负载差异（和少量的带宽占用）。使用 “minpoll” 和 “maxpoll” 选项可以本地设置频率。然而，根据连接 NTP 服务器的规则，你不应该分别修改其默认的 64 秒和 1024 秒。
|
||
|
||
此外，需要提出的是客户应该重视那些请求时间的服务器发出的“<ruby>亲一下就死（死亡之吻）<rt>Kiss-Of-Death</rt></ruby>” （KOD）消息。如果 NTP 服务器不想响应某个特定的请求，就像路由和防火墙技术那样，那么它最有可能的就是简单地遗弃或吞没任何相关的包。
|
||
|
||
换句话说，接受到这些数据的服务器并不需要特别处理这些包，简单地丢弃这些它认为这不值得回应的包即可。你可以想象，这并不是特别好的做法，有时候礼貌地问客户是否中止或停止比忽略请求更为有效。因此，这种特别的包类型叫做 KOD 包。如果一个客户端被发送了这种不受欢迎的 KOD 包，它应该记住这个发回了拒绝访问标志的服务器。
|
||
|
||
如果从该服务器收到不止一个 KOD 包，客户端会猜想服务器上发生了流量限速的情况（或类似的）。这种情况下，客户端一般会写入本地日志，提示与该服务器的交流不太顺利，以备将来排错之用。
|
||
|
||
牢记，出于显而易见的原因，关键在于 NTP 服务器的架构应该是动态的。因此，不要给你的 NTP 配置硬编码 IP 地址是非常重要的。通过使用 DNS 域名，个别服务器断开网络时服务仍能继续进行，而 IP 地址空间也能重新分配，并且可引入简单的负载均衡（具有一定程度的弹性）。
|
||
|
||
请别忘了我们也需要考虑呈指数增长的物联网（IoT），这最终将包括数以亿万计的新装置，意味着这些设备都需要保持正确时间。硬件卖家无意（或有意）设置他们的设备只能与一个提供者的（甚至一个） NTP 服务器连接终将成为过去，这是一个非常麻烦的问题。
|
||
|
||
你可能会想象，随着买入和上线更多的硬件单元，NTP 基础设施的拥有者大概不会为相关的费用而感到高兴，因为他们正被没有实际收入所困扰。这种情形并非杞人忧天。头疼的问题多呢 -- 由于 NTP 流量导致基础架构不堪重负 -- 这在过去几年里已发生过多次。
|
||
|
||
在下面两篇文章里，我将着重于一些重要的 NTP 安全配置选项和描述服务器的搭建。
|
||
|
||
--------------------------------------------------------------------------------
|
||
|
||
via: https://www.linux.com/learn/arrive-time-ntp-part-1-usage-overview
|
||
|
||
作者：[CHRIS BINNIE][a]
|
||
译者：[XYenChi](https://github.com/XYenChi)
|
||
校对：[wxy](https://github.com/wxy)
|
||
|
||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||
|
||
[a]:https://www.linux.com/users/chrisbinnie
|
||
[1]:https://www.linux.com/licenses/category/used-permission
|
||
[2]:https://www.linux.com/files/images/ntp-timejpg
|
||
[3]:http://www.ntp.org/ntpfaq/NTP-s-sw-clocks-quality.htm
|
||
[4]:http://support.ntp.org/bin/view/Servers/StratumOneTimeServers
|