故障记录

修复：维护已完成。此时服务应已恢复在线。如果您的虚拟机仍处于离线状态，请通过 support@lunanode.com 联系我们。

原因：我们正在调查此hypervisor上的磁盘问题。由于该问题，hypervisor当前处于离线状态。

修复：问题已解决。

原因：由于我们的数据中心（Cogent Toronto）将进行维护，网络停机时间最多为 6 小时（尽管预计实际停机时间会短得多）。他们说：“这项工作的目的是按照制造商的建议，对边缘路由器上运行的代码应用并激活软件模块升级。”

原因：我们目前已知悉多伦多数据中心的网络问题正在导致数据包丢失。我们的上游提供商已确定根本原因，并正在积极制定解决方案。一旦获得更多信息，我们将提供进一步更新。

修复：问题已解决。

原因：我们目前已知悉一个网络问题，导致 Toronto 数据中心出现数据包丢失。我们的上游提供商已确定根本原因，并正在积极处理解决方案。我们将在获得更多信息后提供进一步更新。

修复：问题已解决。

原因：由于我们的数据中心（Cogent Toronto）正在执行维护，网络将出现最多 3 小时的停机（尽管预计停机时间会短得多）。他们说：“此次工作的目的是按照制造商的建议，对边缘路由器上运行的代码应用并激活软件模块升级。”

修复：服务已恢复，在我们继续监测情况的同时，我们预计不会出现更多的服务中断。

原因：文件系统修复已完成，虚拟机已恢复。由于磁盘损坏，四台虚拟机上的数据丢失。我们将为受影响的用户补偿三个月的停机时长信用额度和十二个月的数据丢失信用额度——请提交工单以申请将信用额度添加到您的账户。

修复：文件系统修复已完成，虚拟机已恢复。由于磁盘损坏，四台虚拟机上的数据丢失。我们将为受影响的用户补偿三个月的停机时长信用额度和十二个月的数据丢失信用额度——请提交工单以申请将信用额度添加到您的账户。

修复：维护已完成。

原因：服务此时已恢复在线。停机是由于虚拟机监控程序上一个SSD的硬件问题导致的；该SSD需要更换，但由于故障模式（未立即失败），也导致了文件系统数据损坏。文件系统现已修复，但至少有5台虚拟机磁盘损坏。如果您的虚拟机无法工作且您未收到通知，请提交工单。今天晚些时候，我们将向所有受影响的用户发放一个月的免费积分（遇到数据损坏的用户将获得额外积分）。

修复：服务此时已恢复在线。停机是由于虚拟机监控程序上一个SSD的硬件问题导致的；该SSD需要更换，但由于故障模式（未立即失败），也导致了文件系统数据损坏。文件系统现已修复，但至少有5台虚拟机磁盘损坏。如果您的虚拟机无法工作且您未收到通知，请提交工单。今天晚些时候，我们将向所有受影响的用户发放一个月的免费积分（遇到数据损坏的用户将获得额外积分）。

修复：该虚拟机监控程序上的服务已恢复在线。

原因：Cogent 继续处理电力问题，暂无更多更新。

修复：服务似乎已恢复，我们将继续监控。

原因：我们因系统异常错误重启了此虚拟机监控程序。我们将继续监控该虚拟机监控程序的稳定性，以防重启无法解决问题。

原因：由于我们的数据中心（Cogent Toronto）正在执行维护，网络将出现最多一小时的宕机。他们说“此次维护的目的是网络维护硬件和软件升级，需要重启。”

修复：维护已完成。

修复：（已完成）

修复：服务器已重新上线。

原因：我们因系统异常错误重启了此虚拟机监控程序。我们将继续监控该虚拟机监控程序的稳定性，以防重启无法解决问题。

原因：Hypervisor 因磁盘错误宕机

修复：hypervisor 在更换 RAID 控制器后已重新上线。

原因：NameSilo 已重新激活 lndyn.com。服务此时应已恢复。我们尚未收到有关最初暂停原因的更多信息，仅收到其已被重新激活的通知。 我们正在将所有域名从 NameSilo 迁出，原因是我们的用户经历了 24 小时的宕机，以及 NameSilo 在此问题上极为令人担忧的沟通缺失（即使到现在，我们也没有收到任何导致暂停的滥用投诉）。

修复：NameSilo 已重新激活 lndyn.com。服务此时应已恢复。我们尚未收到有关最初暂停原因的更多信息，仅收到其已被重新激活的通知。 我们正在将所有域名从 NameSilo 迁出，原因是我们的用户经历了 24 小时的宕机，以及 NameSilo 在此问题上极为令人担忧的沟通缺失（即使到现在，我们也没有收到任何导致暂停的滥用投诉）。

原因：多伦多的一个 hypervisor（cbec3404b692）因磁盘问题宕机约 10 分钟。该 hypervisor 现已恢复。

修复：多伦多的一个 hypervisor（cbec3404b692）因磁盘问题宕机约 10 分钟。该 hypervisor 现已恢复。

原因：今天发生了一次长时间的故障，原因是诊断问题时错误识别了受影响的hypervisor。识别出正确的hypervisor后，我们通过更换故障磁盘使该hypervisor重新上线。使用该hypervisor作为网络节点的VM的网络连接也受到了影响。

修复：今天发生了一次长时间的故障，原因是诊断问题时错误识别了受影响的hypervisor。识别出正确的hypervisor后，我们通过更换故障磁盘使该hypervisor重新上线。使用该hypervisor作为网络节点的VM的网络连接也受到了影响。

原因：我们已从数据中心获悉，电力问题是由于断路器误跳闸造成的。Cogent表示他们已将断路器更换为新断路器，我们不应再遇到该设备的任何进一步问题。

修复：目前大部分服务已恢复。其余服务应很快就会恢复在线。

原因：丢包问题再次出现。原因是针对多个 IP 的 DDoS 攻击，导致难以进行黑洞路由。我们正在再次努力恢复连接。

修复：服务现在应该已恢复。

原因：一台多伦多虚拟机管理程序（a4120f5bedfa）因硬件故障（磁盘面板）离线20-30分钟。将磁盘更换到备用物理服务器后，服务已恢复。

修复：一台多伦多虚拟机管理程序（a4120f5bedfa）因硬件故障（磁盘面板）离线20-30分钟。将磁盘更换到备用物理服务器后，服务已恢复。

原因：多伦多的一台 hypervisor（1ee830f71342）有一个电源发生故障。由于固件不匹配，我们无法用库存中的电源更换故障电源。

修复：服务已恢复。

修复：服务已恢复。

修复：我们在 Toronto 的上游供应商正在对核心路由器执行软件更新，导致间歇性网络问题。我们预计更新将在接下来的 30 分钟内完成..

原因：由于路由器故障导致的网络问题与“19 October 2022”问题类似，现已再次出现。最近一次网络中断发生在 EST 11:00，持续两分钟。我们昨晚升级了路由器固件，因为变更列表表明它可能解决问题，但并未解决。我们继续寻找替代解决方案，因为此前我们的主路由器和备用路由器都遇到了同样的问题。

修复：服务已恢复在线。

原因：b4fa814b28f1 现已在线。故障发生在一个机架中电源条的例行维护和检查期间。然而，电源利用率似乎因网络交换机故障而激增，导致两个断路器跳闸。电力恢复后，多台虚拟机管理程序在启动时出现问题，其中大部分在移除与根文件系统无关的磁盘后成功启动。 但 b4fa814b28f1 和 1ee830f71342 因过时的分区布局而出现了不同的启动问题，目前尚不清楚为什么它们过去能正常启动而现在却不行；不过，在将分区布局更新为现代格式后，它们也得以恢复。

修复：b4fa814b28f1 现已在线。故障发生在一个机架中电源条的例行维护和检查期间。然而，电源利用率似乎因网络交换机故障而激增，导致两个断路器跳闸。电力恢复后，多台虚拟机管理程序在启动时出现问题，其中大部分在移除与根文件系统无关的磁盘后成功启动。 但 b4fa814b28f1 和 1ee830f71342 因过时的分区布局而出现了不同的启动问题，目前尚不清楚为什么它们过去能正常启动而现在却不行；不过，在将分区布局更新为现代格式后，它们也得以恢复。

原因：蒙特利尔的一台 SSD hypervisor 已离线，原因是数据中心内部网络问题，我们正在等待回复。

修复：控制节点已恢复在线，控制面板功能已恢复

原因：多伦多的一台 hypervisor 因硬件问题发生故障。我们正在调查中。

修复：RAID 阵列修复完成，服务已恢复

原因：今天早上又发生了一次因路由器问题导致的短暂中断，今晚大约美国东部时间21:00我们将更换SFP模块，看看是否是SFP模块的问题。

修复：我们没有再看到更多中断，因此尽管更换后出现了一次最终中断，但 2022 年 10 月 21 日的 SFP 模块更换似乎已解决了该问题。

原因：我们的上游供应商 Cogent Communications 将于 2022 年 7 月 29 日午夜在多伦多数据中心进行网络维护。此次维护将导致我们多伦多区域在 2022 年 7 月 30 日美国东部时间 00:00 至 05:00 之间出现最多 60 分钟的网络中断。

原因：这似乎是由于 46-D06 机架的数据中心中断所致（ http://vms.status-ovhcloud.com/index_rbx6.html ）。我们正在等待数据中心（OVH）的回复。

修复：所有服务已再次恢复在线。

原因：今天多伦多的问题是由最近一场风暴导致数据中心HVAC系统故障引起的，这意味着大量设备过热。我们将收到数据中心（Cogent Toronto）更多信息后发布更新。

修复：HVAC机组正在恢复中，服务器上的温度告警正在解除。

修复：网络升级已完成，为使新配置生效，该区域内的虚拟机必须重启。对于造成的不便，我们深表歉意。

原因：由于数据中心内的网络维护，蒙特利尔的部分服务出现停机。详情请参阅 OVH 网页。

修复：更新：服务已经恢复在线。

原因：同一个Montreal SSD hypervisor（55d26960353e）因无关问题（OVH vRack中断）再次离线，直至约19:10 EST。

修复：服务已恢复在线。我们相信反复出现的内核崩溃问题已解决。

修复：服务已恢复在线。

修复：服务已恢复在线。

修复：我们已解决多伦多一个 SSD 虚拟机管理程序（b3700f1d6136）的停机问题。服务已于此时恢复在线（06:03 EST）。

修复：服务已恢复在线。

原因：之前出现读取错误的第二块磁盘现在也已更换，RAID1 构建已完成。此时两块磁盘均已更换，RAID1 阵列状态良好。

修复：服务此时应已恢复。如果您的 VM 仍处于离线状态，请提交工单。

修复：服务已恢复在线。

原因：我们正在调查鲁贝的网络停机。由于我们在鲁贝使用的数据中心（OVH）的vrack基础设施出现问题，服务似乎离线。

修复：服务已恢复。

修复：服务已恢复。目前尚不清楚中断是由数据中心基础设施问题还是我们的网络节点服务器出现内核锁定所致。我们将继续调查。

修复：服务已恢复。

原因：由于检测到 Roubaix 虚拟化主机 e3ba7defacb5 上存在潜在磁盘问题，我们将执行紧急维护，包括将全部虚拟机从该虚拟化主机迁移至其他虚拟化主机。这将涉及每台虚拟机的重启，停机时间为 2-10 分钟，具体取决于虚拟机的磁盘大小。维护将立即开始。

原因：由于一些问题，维护改在 23:45 进行。但目前已完成，大多数服务经历了最多 2 分钟的网络中断。

修复：服务已恢复在线。

原因：位于 Montreal 的一个 SSD hypervisor（de6e4fa83fdc）因磁盘问题离线进行紧急维护。我们预计会有 10-20 分钟的停机时间。

修复：RFO：我们的监控系统检测到 RAID10 组中的一个磁盘今早发生故障。我们在蒙特利尔和鲁贝使用 OVH 的服务，并请求更换磁盘。看起来他们需要关闭服务器来更换磁盘，而不是热插拔。但现在 RAID10 组已恢复正常。请注意，在我们的主要站点多伦多，我们始终可以热插拔磁盘。

修复：服务已恢复在线。

原因：停机是由内核崩溃导致的。我们将进一步检查，以确定当前内核是否足以避免该停机事件在未来再次发生。

修复：服务已恢复在线。

原因：由于与旧内核相关的内存错误，我们正在对 Toronto 的 hypervisor 7fd1830faf11 执行紧急维护。需要停机十分钟以更新到新内核来解决这些问题。

修复：服务已恢复在线。

原因：由于上游问题，服务在 21:10 EDT 至 21:20 EDT 期间处于离线状态。详情请参见 http://travaux.ovh.net/?do=details&id=46759。

原因：由于上游（OVH）vrack 网络问题，网络再次宕机。

修复：服务已恢复在线。

原因：由于上游（OVH）vrack问题，网络中断。http://travaux.ovh.net/?do=details&id=45816

修复：服务已恢复在线。

原因：Hypervisor 1ee830f71342 因电源线张力问题以及技术人员在设备安装/迁移至新的 20A 电路过程中的操作失误而离线。服务应在五到十分钟内恢复在线。

修复：服务已恢复在线。

原因：RFO 更新（2020年7月6日 21:00 EDT）：故障摘要：2020年7月6日 10:05 EDT，Cogent 位于多伦多 245 Consumers Rd 的数据中心发生电涌，导致服务器重启以及我们其中一个机架中的一台 PDU 故障。（其他 Cogent 客户也受到影响，全天数据中心相当拥挤。）由于 PDU 故障，该机架中的服务器未能重新上线。 我们的技术人员决定在 11:00 更换 PDU，大多数服务器开始正常启动，但四台服务器在启动时出现问题。其中一台于美国东部时间 11:50 上线，此时不依赖卷存储系统的服务（除其他服务器上的虚拟机外）得以恢复上线。 其他三台服务器的确切问题尚不清楚，但在重新插拔RAID控制器、取出…

修复：RFO 更新（2020年7月6日 21:00 EDT）：故障摘要：2020年7月6日 10:05 EDT，Cogent 位于多伦多 245 Consumers Rd 的数据中心发生电涌，导致服务器重启以及我们其中一个机架中的一台 PDU 故障。（其他 Cogent 客户也受到影响，全天数据中心相当拥挤。）由于 PDU 故障，该机架中的服务器未能重新上线。 我们的技术人员决定在 11:00 更换 PDU，大多数服务器开始正常启动，但四台服务器在启动时出现问题。其中一台于美国东部时间 11:50 上线，此时不依赖卷存储系统的服务（除其他服务器上的虚拟机外）得以恢复上线。 其他三台服务器的确切问题尚不清楚，但在重新插拔RAID控制器、取出…

修复：更换硬件组件后，服务已恢复在线。

修复：昨晚的重启未解决延迟问题，但我们今天应用额外的调整步骤，并确认问题已解决且延迟低且稳定。

原因：最终数据中心就此事件提出了问题：http://travaux.ovh.net/?do=details&id=45319& 。同时，此时网络连接完全离线。由于数据中心问题，我们从14:40 EDT开始观察到Roubaix出现严重的丢包现象。我们正在联系数据中心以调查此问题。

修复：网络现已恢复在线，但仍可能非常不稳定。我们完全没有收到数据中心的任何更新。

原因：由于数据中心（OVH）问题，Roubaix 服务处于离线状态。

修复：服务已恢复在线。

修复：服务在五分钟后恢复在线。

原因：服务在八分钟后恢复在线。我们需要稍后确认错误已消失。

修复：服务在八分钟后恢复在线。我们需要稍后确认错误已消失。

修复：服务已恢复在线。

原因：一台 Montreal SSD hypervisor 因数据中心 vrack 问题（OVH）出现网络停机。

修复：他们已修复，现已恢复在线。

原因：一台 Roubaix SSD hypervisor 因紧急维护在 EDT 16:45 至 16:55 离线十分钟，以修复导致高延迟和丢包的内核问题。

修复：服务已恢复在线。

原因：我们在多伦多仍然看到 1% 的数据包丢失。这似乎不是数据中心范围内的问题。我们的团队已在现场并仍在调查中。我们可能会切换到备用路由器或执行其他类似操作，这些操作可能导致短暂的网络中断（不到一分钟）。

修复：我们未发现任何进一步的问题。更新 3（09 April 2020 13:25 EDT）：服务目前已恢复在线。我们会继续监控 hypervisor，但我们认为问题应该已经解决。

原因：我们目前看到因数据中心问题导致的网络中断。

修复：服务目前已经恢复在线。这是 OVH 的问题。

原因：由于Cogent的计划性网络维护，Toronto在EDT 00:00至EDT 03:00之间可能会有30-60分钟的网络停机。

修复：服务目前已恢复在线。

原因：由于数据中心问题，蒙特利尔一台虚拟机监控程序（hypervisor）上虚拟机的内网和外网均离线。我们正在与 OVH 沟通以解决该问题。

修复：服务目前已经恢复在线。这是 OVH 的问题。

修复：服务目前已恢复在线。

原因：由于我们在蒙特利尔和鲁贝使用的数据中心大幅提高了成本，我们将于2023年1月31日停止这些地点的服务。

补偿/善后：请务必在 2023 年 1 月 31 日之前迁移您的 VM。在 2023 年 1 月 31 日之前迁移的 VM 将获得三个月的免费额度。