mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-26 21:30:55 +08:00
173 lines
20 KiB
Markdown
173 lines
20 KiB
Markdown
IT 灾备：系统管理员对抗自然灾害
|
||
======
|
||
|
||
|
||
|
||
> 面对倾泻的洪水或地震时业务需要继续运转。在飓风卡特里娜、桑迪和其他灾难中幸存下来的系统管理员向在紧急状况下负责 IT 的人们分享真实世界中的建议。
|
||
|
||
说到自然灾害，2017 年可算是多灾多难。（LCTT 译注：本文发表于 2017 年）飓风哈维、厄玛和玛莉亚给休斯顿、波多黎各、弗罗里达和加勒比造成了严重破坏。此外，西部的野火将多处住宅和商业建筑付之一炬。
|
||
|
||
再来一篇关于[有备无患][1]的警示文章 —— 当然其中都是好的建议 —— 是很简单的，但这无法帮助网络管理员应对湿漉漉的烂摊子。那些善意的建议中大多数都假定掌权的人乐于投入资金来实施这些建议。
|
||
|
||
我们对真实世界更感兴趣。不如让我们来充分利用这些坏消息。
|
||
|
||
一个很好的例子：自然灾害的一个后果是老板可能突然愿意给灾备计划投入预算。如同一个纽约地区的系统管理员所言，“[我发现飓风桑迪的最大好处][2]是我们的客户对 IT 投资更有兴趣了，但愿你也能得到更多预算。”
|
||
|
||
不过别指望这种意愿持续很久。任何想提议改进基础设施的系统管理员最好趁热打铁。如同另一位飓风桑迪中幸存下来的 IT 专员懊悔地提及那样，“[对 IT 开支最初的兴趣持续到当年为止][3]。到了第二年，任何尚未开工的计划都因为‘预算约束’被搁置了，大约 6 个月之后则完全被遗忘。”
|
||
|
||
在管理层忘记恶劣的自然灾害也可能降临到好公司头上之前提醒他们这点会有所帮助。根据<ruby>商业和家庭安全协会<rt>Institute for Business & Home Safety</rt></ruby>的说法，[自然灾害后歇业的公司中 25% 再也没能重新开业][4]。<ruby>联邦紧急事务管理署<rt>FEMA</rt></ruby>认为这过于乐观。根据他们的统计，“灾后 [40% 的小公司再也没能重新开门营业][5]。”
|
||
|
||
如果你是个系统管理员，你能帮忙挽救你的公司。这里有一些幸存者的最好的主意，这些主意是基于他们从过去几次自然灾害中得到的经验。
|
||
|
||
### 制订一个计划
|
||
|
||
当灯光忽明忽暗，狂风象火车机车一样怒号时，就该启动你的业务持续计划和灾备计划了。
|
||
|
||
有太多的系统管理员报告当暴风雨来临时这两个计划中一个也没有。这并不令人惊讶。2014 年<ruby>[灾备预备状态委员会][6]<rt>Disaster Recovery Preparedness Council</rt></ruby>发现[世界范围内被调查的公司中有 73% 没有足够的灾备计划][7]。
|
||
|
||
“**足够**”是关键词。正如一个系统管理员 2016 年在 Reddit 上写的那样，“[我们的灾备计划就是一场灾难。][8]我们所有的数据都备份在离这里大约 30 英里的一个<ruby>存储区域网络<rt>SAN</rt></ruby>。我们没有将数据重新上线的硬件，甚至好几天过去了都没能让核心服务器启动运行起来。我们是个年营收 40 亿美元的公司，却不愿为适当的设备投入几十万美元，或是在数据中心添置几台服务器。当添置硬件的提案被提出的时候，我们的管理层说，‘嗐，碰到这种事情的机会能有多大呢’。”
|
||
|
||
同一个帖子中另一个人说得更简洁：“眼下我的灾备计划只能在黑暗潮湿的角落里哭泣，但愿没人在乎损失的任何东西。”
|
||
|
||
如果你在哭泣，但愿你至少不是独自流泪。任何灾备计划，即便是 IT 部门制订的灾备计划，必须确定[你能跟别人通讯][10]，如同系统管理员 Jim Thompson 从卡特里娜飓风中得到的教训：“确保你有一个与人们通讯的计划。在一场严重的区域性灾难期间，你将无法给身处灾区的任何人打电话。”
|
||
|
||
有一个选择可能会让有技术头脑的人感兴趣：<ruby>[业余电台][11]<rt>ham radio</rt></ruby>。[它在波多黎各发挥了巨大作用][12]。
|
||
|
||
### 列一个愿望清单
|
||
|
||
第一步是承认问题。“许多公司实际上对灾备计划不感兴趣，或是消极对待”，[Micro Focus][14] 的首席架构师 [Joshua Focus][13] 说。“将灾备看作业务持续性的一个方面是种不同的视角。所有公司都要应对业务持续性，所以灾备应被视为业务持续性的一部分。”
|
||
|
||
IT 部门需要将其需求书面化以确保适当的灾备和业务持续性计划。即使是你不知道如何着手，或尤其是这种时候，也是如此。正如一个系统管理员所言，“我喜欢有一个‘想法转储’，让所有计划、点子、改进措施毫无保留地提出来。（这）[对一类情况尤其有帮助，即当你提议变更][15]，并付诸实施，接着 6 个月之后你警告过的状况就要来临。”现在你做好了一切准备并且可以开始讨论：“如同我们之前在 4 月讨论过的那样……”
|
||
|
||
因此，当你的管理层对业务持续性计划回应道“嗐，碰到这种事的机会能有多大呢？”的时候你能做些什么呢？有个系统管理员称这也完全是管理层的正常行为。在这种糟糕的处境下，老练的系统管理员建议用书面形式把这些事情记录下来。记录应清楚表明你告知管理层需要采取的措施，且[他们拒绝采纳建议][16]。“总的来说就是有足够的书面材料能让他们搓成一根绳子上吊，”该系统管理员补充道。
|
||
|
||
如果那也不起作用，恢复一个被洪水淹没的数据中心的相关经验对你[找个新工作][17]是很有帮助的。
|
||
|
||
### 保护有形的基础设施
|
||
|
||
“[我们的办公室是幢摇摇欲坠的建筑][18]，”飓风哈维重创休斯顿之后有个系统管理员提到。“我们盲目地进入那幢建筑，现场的基础设施糟透了。正是我们给那幢建筑里带去了最不想要的一滴水，现在基础设施整个都沉在水下了。”
|
||
|
||
尽管如此，如果你想让数据中心继续运转——或在暴风雨过后恢复运转 —— 你需要确保该场所不仅能经受住你所在地区那些意料中的灾难，而且能经受住那些意料之外的灾难。一个旧金山的系统管理员知道为什么重要的是确保公司的服务器安置在可以承受里氏 7 级地震的建筑内。一家圣路易斯的公司知道如何应对龙卷风。但你应当为所有可能发生的事情做好准备：加州的龙卷风、密苏里州的地震，或[僵尸末日][19]（给你在 IT 预算里增加一把链锯提供了充分理由）。
|
||
|
||
在休斯顿的情况下，[多数数据中心保持运转][20]，因为它们是按照抵御暴风雨和洪水的标准建造的。[Data Foundry][21] 的首席技术官 Edward Henigin 说他们公司的数据中心之一，“专门建造的休斯顿 2 号的设计能抵御 5 级飓风的风速。这个场所的公共供电没有中断，我们得以避免切换到后备发电机。”
|
||
|
||
那是好消息。坏消息是伴随着超级飓风桑迪于 2012 年登场，如果[你的数据中心没准备好应对洪水][22]，你会陷入一个麻烦不断的世界。一个不能正常运转的数据中心 [Datagram][23] 服务的客户包括 Gawker、Gizmodo 和 Buzzfeed 等知名网站。
|
||
|
||
当然，有时候你什么也做不了。正如某个波多黎各圣胡安的系统管理员在飓风厄玛扫过后悲伤地写到，“发电机没油了。服务器机房靠电池在运转但是没有（空调）。[永别了，服务器][24]。”由于 <ruby>MPLS<rt>Multiprotocol Lable Switching</rt></ruby> 线路亦中断，该系统管理员没法切换到灾备措施：“多么充实的一天。”
|
||
|
||
总而言之，IT 专业人士需要了解他们所处的地区，了解他们面临的风险并将他们的服务器安置在能抵御当地自然灾害的数据中心内。
|
||
|
||
### 关于云的争议
|
||
|
||
当暴风雨席卷一切时避免 IT 数据中心失效的最佳方法就是确保灾备数据中心在其他地方。选择地点时需要审慎的决策。你的灾备数据中心不应在会被同一场自然灾害影响到的<ruby>地域<rt>region</rt></ruby>；你的资源应安置在多个<ruby>可用区<rt>availability zone</rt></ruby>内。考虑一下主备数据中心位于一场地震中的同一条断层带上，或是主备数据中心易于受互通河道导致的洪灾影响这类情况。
|
||
|
||
有些系统管理员[利用云作为冗余设施][25]。例如，总是用微软 Azure 云存储服务保存副本以确保持久性和高可用性。根据你的选择，Azure 复制功能将你的数据要么拷贝到同一个数据中心要么拷贝到另一个数据中心。多数公有云提供类似的自动备份服务以确保数据安全，不论你的数据中心发生什么情况——除非你的云服务供应商全部设施都在暴风雨的行进路径上。
|
||
|
||
昂贵么？是的。跟业务中断 1、2 天一样昂贵么？并非如此。
|
||
|
||
信不过公有云？可以考虑 <ruby>colo<rt>colocation</rt></ruby> 服务。有了 colo，你依旧拥有你的硬件，运行你自己的应用，但这些硬件可以远离麻烦。例如飓风哈维期间，一家公司“虚拟地”将它的资源从休斯顿搬到了其位于德克萨斯奥斯汀的 colo。但是那些本地数据中心和 colo 场所需要准备好应对灾难；这点是你选择场所时要考虑的一个因素。举个例子，一个寻找 colo 场所的西雅图系统管理员考虑的“全都是抗震和旱灾应对措施（加固的地基以及补给冷却系统的运水卡车）。”
|
||
|
||
### 周围一片黑暗时
|
||
|
||
正如 Forrester Research 的分析师 Rachel Dines 在一份为[灾备期刊][27]所做的调查中报告的那样，宣布的灾难中[最普遍的原因就是断电][26]。尽管你能应对一般情况下的断电，飓风、火灾和洪水的考验会超越设备的极限。
|
||
|
||
某个系统管理员挖苦式的计划是什么呢？“趁 UPS 完蛋之前把你能关的机器关掉，不能关的就让它崩溃咯。然后，[喝个痛快直到供电恢复][28]。”
|
||
|
||
在 2016 年德尔塔和西南航空停电事故之后，IT 员工推动的一个更加严肃的计划是由一个有管理的服务供应商为其客户[部署不间断电源][29]：“对于至关重要的部分，在供电中断时我们结合使用<ruby>简单网络管理协议<rt>SNMP</rt></ruby>信令和 <ruby>PowerChute 网络关机<rt>PowerChute Nrework Shutdown</rt></ruby>客户端来关闭设备。至于重新开机，那取决于客户。有些是自动启动，有些则需要人工干预。”
|
||
|
||
另一种做法是用来自两个供电所的供电线路支持数据中心。例如，[西雅图威斯汀大厦数据中心][30]有来自不同供电所的多路 13.4 千伏供电线路，以及多个 480 伏三相变电箱。
|
||
|
||
预防严重断电的系统不是“通用的”设备。系统管理员应当[为数据中心请求一台定制的柴油发电机][31]。除了按你特定的需求调整，发电机必须能迅速跳至全速运转并承载全部电力负荷而不致影响系统负载性能。”
|
||
|
||
这些发电机也必须加以保护。例如，将你的发电机安置在泛洪区的一楼就不是个聪明的主意。位于纽约<ruby>百老街<rt>Broad street</rt></ruby>的数据中心在超级飓风桑迪期间就是类似情形，备用发电机的燃料油桶在地下室 —— 并且被水淹了。尽管一场[“人力接龙”用容量 5 加仑的水桶将柴油输送到 17 段楼梯之上的发电机][32]使 [Peer 1 Hosting][33] 得以继续运营，但这不是一个切实可行的业务持续计划。
|
||
|
||
正如多数数据中心专家所知那样，如果你有时间 —— 假设一个飓风离你有一天的距离 —— 确保你的发电机正常工作，加满油，准备好当供电线路被刮断时立即开启，不管怎样你之前应当每月测试你的发电机。你之前是那么做的，是吧？是就好！
|
||
|
||
### 测试你对备份的信心
|
||
|
||
普通用户几乎从不备份，检查备份是否实际完好的就更少了。系统管理员对此更加了解。
|
||
|
||
有些 [IT 部门在寻求将他们的备份迁移到云端][34]。但有些系统管理员仍对此不买账 —— 他们有很好的理由。最近有人报告，“在用了整整 5 天[从亚马逊 Glacier 恢复了（400 GB）数据][35]之后，我欠了亚马逊将近 200 美元的传输费，并且（我还是）处于未完全恢复状态，还差大约 100 GB 文件。”
|
||
|
||
结果是有些系统管理员依然喜欢磁带备份。磁带肯定不够时髦，但正如操作系统专家 Andrew S. Tanenbaum 说的那样，“[永远不要低估一辆装满磁带在高速上飞驰的旅行车的带宽][36]。”
|
||
|
||
目前每盘磁带可以存储 10 TB 数据；有的进行中的实验可在磁带上存储高达 200 TB 数据。诸如<ruby>[线性磁带文件系统][37]<rt>Linear Tape File System</rt></ruby>之类的技术允许你象访问网络硬盘一样读取磁带数据。
|
||
|
||
然而对许多人而言，磁带[绝对是最后选择的手段][38]。没关系，因为备份应该有大量的可选方案。在这种情况下，一个系统管理员说到，“故障时我们会用这些方法（恢复备份）：（Windows）服务器层面的 VSS （Volume Shadow Storage）快照，<ruby>存储区域网络<rt>SAN</rt></ruby>层面的卷快照，以及存储区域网络层面的异地归档快照。但是万一有什么事情发生并摧毁了我们的虚拟机，存储区域网络和备份存储区域网络，我们还是可以取回磁带并恢复数据。”
|
||
|
||
当麻烦即将到来时，可使用副本工具如 [Veeam][39]，它会为你的服务器创建一个虚拟机副本。若出现故障，副本会自动启动。没有麻烦，没有手忙脚乱，正如某个系统管理员在这个流行的系统管理员帖子中所说，“[我爱你 Veeam][40]。”
|
||
|
||
### 网络？什么网络？
|
||
|
||
当然，如果员工们无法触及他们的服务，没有任何云、colo 和远程数据中心能帮到你。你不需要一场自然灾害来证明冗余互联网连接的正确性。只需要一台挖断线路的挖掘机或断掉的光缆就能让你在工作中渡过糟糕的一天。
|
||
|
||
“理想状态下”，某个系统管理员明智地观察到，“你应该有[两路互联网接入线路连接到有独立基础设施的两个 ISP][41]。例如，你不希望两个 ISP 都依赖于同一根光缆。你也不希望采用两家本地 ISP，并发现他们的上行带宽都依赖于同一家骨干网运营商。”
|
||
|
||
聪明的系统管理员知道他们公司的互联网接入线路[必须是商业级别的][43]，带有<ruby>服务等级协议<rt>service-level agreement(SLA)</rt></ruby>，其中包含“修复时间”条款。或者更好的是采用<ruby>互联网接入专线<rt></rt>dedicated Internet access</ruby>。技术上这与任何其他互联网接入方式没有区别。区别在于互联网接入专线不是一种“尽力而为”的接入方式，而是你会得到明确规定的专供你使用的带宽并附有服务等级协议。这种专线不便宜，但正如一句格言所说的那样，“速度、可靠性、便宜，只能挑两个。”当你的业务跑在这条线路上并且一场暴风雨即将来袭，“可靠性”必须是你挑的两个之一。
|
||
|
||
### 晴空重现之时
|
||
|
||
你没法准备应对所有自然灾害，但你可以为其中很多做好计划。有一个深思熟虑且经过测试的灾备和业务持续计划，并逐字逐句严格执行，当竞争对手溺毙的时候，你的公司可以幸存下来。
|
||
|
||
### 系统管理员对抗自然灾害：给领导者的教训
|
||
|
||
* 你的 IT 员工得说多少次：不要仅仅备份，还得测试备份？
|
||
* 没电就没公司。确保你的服务器有足够的应急电源来满足业务需要，并确保它们能正常工作。
|
||
* 如果你的公司在一场自然灾害中幸存下来，或者避开了灾害，明智的系统管理员知道这就是向管理层申请被他们推迟的灾备预算的时候了。因为下次你就未必有这么幸运了。
|
||
|
||
|
||
--------------------------------------------------------------------------------
|
||
|
||
via: https://www.hpe.com/us/en/insights/articles/it-disaster-recovery-sysadmins-vs-natural-disasters-1711.html
|
||
|
||
作者：[Steven-J-Vaughan-Nichols][a]
|
||
译者：[0x996](https://github.com/0x996)
|
||
校对：[wxy](https://github.com/wxy)
|
||
|
||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||
|
||
[a]:https://www.hpe.com/us/en/insights/contributors/steven-j-vaughan-nichols.html
|
||
[1]:https://www.hpe.com/us/en/insights/articles/what-is-disaster-recovery-really-1704.html
|
||
[2]:https://www.reddit.com/r/sysadmin/comments/6wricr/dear_houston_tx_sysadmins/
|
||
[3]:https://www.reddit.com/r/sysadmin/comments/6wricr/dear_houston_tx_sysadmins/dma6gse/
|
||
[4]:https://disastersafety.org/wp-content/uploads/open-for-business-english.pdf
|
||
[5]:https://www.fema.gov/protecting-your-businesses
|
||
[6]:http://drbenchmark.org/about-us/our-council/
|
||
[7]:https://www.prnewswire.com/news-releases/global-benchmark-study-reveals-73-of-companies-are-unprepared-for-disaster-recovery-248359051.html
|
||
[8]:https://www.reddit.com/r/sysadmin/comments/3cob1k/what_does_your_disaster_recovery_plan_look_like/csxh8sn/
|
||
[9]:https://www.hpe.com/us/en/resources/servers/datacenter-trends-challenges.html?jumpid=in_insights~510287587~451research_datacenter~sjvnSysadmin
|
||
[10]:http://www.theregister.co.uk/2015/07/12/surviving_hurricane_katrina
|
||
[11]:https://theprepared.com/guides/beginners-guide-amateur-ham-radio-preppers/
|
||
[12]:http://www.npr.org/2017/09/29/554600989/amateur-radio-operators-stepped-in-to-help-communications-with-puerto-rico
|
||
[13]:http://www8.hp.com/us/en/software/joshua-brusse.html
|
||
[14]:https://www.microfocus.com/
|
||
[15]:https://www.reddit.com/r/sysadmin/comments/6wricr/dear_houston_tx_sysadmins/dma87xv/
|
||
[16]:https://www.hpe.com/us/en/insights/articles/my-boss-asked-me-to-do-what-how-to-handle-worrying-work-requests-1710.html
|
||
[17]:https://www.hpe.com/us/en/insights/articles/sysadmin-survival-guide-1707.html
|
||
[18]:https://www.reddit.com/r/sysadmin/comments/6wk92q/any_houston_admins_executing_their_dr_plans_this/dm8xj0q/
|
||
[19]:https://community.spiceworks.com/how_to/1243-ensure-your-dr-plan-is-ready-for-a-zombie-apocolypse
|
||
[20]:http://www.datacenterdynamics.com/content-tracks/security-risk/houston-data-centers-withstand-hurricane-harvey/98867.article
|
||
[21]:https://www.datafoundry.com/
|
||
[22]:http://www.datacenterknowledge.com/archives/2012/10/30/major-flooding-nyc-data-centers
|
||
[23]:https://datagram.com/
|
||
[24]:https://www.reddit.com/r/sysadmin/comments/6yjb3p/shutting_down_everything_blame_irma/
|
||
[25]:https://www.hpe.com/us/en/insights/articles/everything-you-need-to-know-about-clouds-and-hybrid-it-1701.html
|
||
[26]:https://www.drj.com/images/surveys_pdf/forrester/2011Forrester_survey.pdf
|
||
[27]:https://www.drj.com
|
||
[28]:https://www.reddit.com/r/sysadmin/comments/4x3mmq/datacenter_power_failure_procedures_what_do_yours/d6c71p1/
|
||
[29]:https://www.reddit.com/r/sysadmin/comments/4x3mmq/datacenter_power_failure_procedures_what_do_yours/
|
||
[30]:https://cloudandcolocation.com/datacenters/the-westin-building-seattle-data-center/
|
||
[31]:https://www.techrepublic.com/article/what-to-look-for-in-a-data-center-backup-generator/
|
||
[32]:http://www.datacenterknowledge.com/archives/2012/10/31/peer-1-mobilizes-diesel-bucket-brigade-at-75-broad
|
||
[33]:https://www.cogecopeer1.com/
|
||
[34]:https://www.reddit.com/r/sysadmin/comments/7a6m7n/aws_glacier_archival/
|
||
[35]:https://www.reddit.com/r/sysadmin/comments/63mypu/the_dangers_of_cloudberry_and_amazon_glacier_how/
|
||
[36]:https://en.wikiquote.org/wiki/Andrew_S._Tanenbaum
|
||
[37]:http://www.snia.org/ltfs
|
||
[38]:https://www.reddit.com/r/sysadmin/comments/5visaq/backups_how_many_of_you_still_have_tapes/de2d0qm/
|
||
[39]:https://helpcenter.veeam.com/docs/backup/vsphere/failover.html?ver=95
|
||
[40]:https://www.reddit.com/r/sysadmin/comments/5rttuo/i_love_you_veeam/
|
||
[41]:https://www.reddit.com/r/sysadmin/comments/5rmqfx/ars_surviving_a_cloudbased_disaster_recovery_plan/dd90auv/
|
||
[42]:https://www.hpe.com/us/en/insights/articles/how-do-you-evaluate-cloud-service-agreements-and-slas-very-carefully-1705.html
|
||
[43]:http://www.e-vergent.com/what-is-dedicated-internet-access/
|