服务器 Gind.cn

服务器问题集锦,包括 Linux(Ubuntu, Centos,Debian等)和Windows Server服务器

在线时使用NTP同步时钟,在离线时使用RTC?

是否有一个现有的机制,可以在线同步一个linux系统与NTP,并且在离线状态下可预测漂移RTC? 我们操作远程“收集器”:收集传感器数据并对其进行时间标记的embedded式Linux系统。 我们需要他们的时钟错误保持合理的小,比如5秒以内。 通常我们使用NTP来同步他们的时钟,并且工作正常 – 只要系统在线。 问题是一些collections家有非常糟糕的上行链路,可能会下降数小时,数天甚至数周。 这并不能阻止本地数据收集,但是如果没有NTP,Linux系统时钟会发生严重的漂移,并且相当不可预测。 OTOH,硬件的RTC漂移也很厉害,但速度不变。 RTC漂移率因板而异,但每块板不变,可以测量。 我想我们需要的是一个机制,做到以下几点: 在部署之前测量电路板的RTC漂移率 如有可能,通过NTP定期调整系统时间 当NTP不可用时,定期从RTC调整系统时间。 考虑已知的RTC漂移率。 可选:测量并logging在线时正在进行的RTC漂移率(1) 对于“机制”,我的意思是一些维护良好,logging在案的软件和/或configuration可以处理“在线”与“离线”两种状态,确保系统时钟与正确的时间源同步(ntp vs. rtc),检测状态变化,并校正RTC漂移。 不pipe它是作为一个特殊的ntpdconfiguration/插件,作为单独的守护进程,还是作为一个cron作业来实现,都没关系。 我看了一下Chrony ,但是根据它的文档,它试图预测系统时钟的漂移,在我们的例子中漂移比RTC漂移更加不可预测。 Chrony似乎只使用RTC来保持重新启动的时间。 (1)注意ntpd激活内核的“11分钟模式”(每隔11分钟从系统时钟更新rtc)。 目前的内核和ntpd似乎没有办法阻止11分钟的模式。 因此,当ntpd正在运行(thx @billthor)时,任何rtc漂移信息都会丢失。 更新/编辑: 我们正在考虑通过USB或串行为MSF或DCF77信号(我们位于欧洲)添加一个外部无线电时钟。 但我们宁愿保持硬件精益。 我们的collections家位于室内,通常在地下室。 所以添加GPS时钟将无济于事。 我们使用Debian 7.这意味着来自util-linux-2.20.1的hwclock,来自ntp-4.2.6.p5的ntpdate-4.2.6p5,ntpd,chrony-1.24(可能是1.30)。 请注意,我们的问题不是我们不知道如何使用ntpdate(8) , hwclock(8) , date(1)等。请参阅斜体添加的部分关于我的意思是“机制”。 增加了关于“11分钟模式”的脚注 这是一个关于离线同步和RTC漂移的非常有趣的讨论

Docker / Ansible与AWS中的Ansible,Puppet和Foreman不可变的服务器模型?

我们正在遇到一个有趣的争论,正在陷入两个阵营。 我感兴趣的任何想法或陷阱我们可能会失踪的任何特定的问题。 真的,任何能够帮助我们做出决定的东西,或者指出我们没有考虑到的事情。 我知道这个裙带着“无意见”的规则,但我希望这仍然是一个可以接受的问题。 对不起,长度也有一些微妙的差别。 1)一方(我 – 我不是没有偏见)发现云系统非常有趣的不变的服务器模型。 为此,我们将基础架构的所有组件移植到Docker中。 我们的自定义应用程序通过Jenkins直接构build到部署到本地Docker Registry的Docker镜像中。 然后,我们创build了一大组Ansibleangular色和一个能够伸手去找空服务器的剧本,安装Docker,然后告诉Docker根据需要安装所有的容器。 几分钟后,整个应用程序及其所有的支持基础架构就被连接起来并工作 – logging,监视,数据库创build/填充等。完成的机器是一个独立的QA或开发环境,具有应用。 我们计划扩大规模的计划是制作新的手册,从基础可信AMI(可能是一张非常光滑的图像)构build新的AWS服务器,对生产应用程序进行滚动部署以处理configurationpipe理和发布,而且通常不会再次编辑服务器 – 只是让他们重新。 我并不担心在实践中得到我所描述的工作 – 只要这是一个合理的模型。 2)另一个阵营希望使用Puppet来处理configurationpipe理,Ansible部署我们的自定义应用程序,这些应用程序是我们构build过程中生成的压缩包,Foreman负责处理整个stream程的触发和pipe理,Katello做一些基础图像pipe理。 发布将涉及Puppet根据需要更改configuration和Ansible部署更新的组件与一定数量的工头协调。 如果我们需要新的服务器,那么服务器的build立就会相当快,但是不要把它们作为标准stream程的一部分来处理。 尽pipe使用寿命长,但它更接近凤凰服务器模式。 所以我的问题真的归结为这个:是不是一成不变的服务器模型,我已经用上面描述的这些工具实际上是现实的了? 我喜欢这样一个想法,即我们的暂存过程实际上可以在现场构build完整的应用程序副本,让QA锤击它,然后只是翻转数据库存储和一些DNS设置以使其生存。 还是不可变的服务器模型在实践中失败? 我们在AWS和云环境方面拥有丰富的经验,所以这不是关注的问题 – 更重要的是如何让一个相当复杂的应用程序可靠地部署到今后。 这是我们特别感兴趣的,因为我们经常发布。 我们有Ansible,除了为我们创buildEC2服务器之外,还需要做大部分工作,这并不困难。 我很难理解为什么你真的需要木偶/工头/ Katello在这个模型中。 Docker比任何自定义的部署脚本更加清洁和简单。 Ansible似乎比Puppet简单得多,当你不必担心必须现场configuration它们,而只需使用新configuration再次构build它们。 我是KISS校长的粉丝,尤其是在墨菲法则猖獗的自动化领域。 国际海事组织越好,机械越less。 任何想法/意见或build议的方法将不胜感激!