データセンタのファシリティマネジメント

電子機器部品メーカの情報システム子会社である W 社は，自社データセンタ（以下，DC という）で，自社業務に使用する各システムを稼働させている。
DC にはコンピュータ室が 2 室あり，それぞれのコンピュータ室にはラックが設置され，サーバが収容されている。DC には，ファシリティマネジメント部（以下，FM 部という）とシステム運用部があり，事務室で執務している。FM 部は，24 時間のシフト体制で担当者が 2 名常駐し，DC 設備の監視と管理を行っている。システム運用部は，24 時間のシフト体制でオペレータが 4 名常駐し，システムの運用と管理を行っている。
DC は，常用電源として電力会社から電力供給を受けている。電力会社からの電力供給に異常が発生した場合に備え，予備電源として自家発電設備（以下，自家発という）を設置している。
電力会社からの電力供給で瞬断が発生した場合や，自家発による電力供給に切替えを行う場合には，コンピュータ室への電力供給が一時的に停止する。これに備えて，蓄電池を持つ UPS をラックに接続して，UPS からラックに電力供給を行っている。UPS からラックなどの電力負荷機器に連続給電できる時間（以下，停電補償時間という）は，負荷の容量に応じて変動する。
UPS は，一部を冗長構成にするための予備の UPS を含めて，7 台設置している。UPS で機器故障が発生した場合は，無瞬断切替え装置によって自動的に予備の UPS からの電力供給に切り替わる。
また，近年のラック内機器の高集積化に伴う発熱量増加を受けて，コンピュータ室に設置している空調機が全て停止することを防ぐために，一部の空調機も UPS に接続して，UPS から空調機に電力供給を行うこととしている。
DC の電力供給設備と電力負荷機器を図 1 に示す。

（1）自家発の課題
自家発は，出力容量 7,500kVA の電力供給能力があるが，W 社の事業拡大に伴い計画された 2021 年度のサーバ機器増強計画に基づき，電力供給設備の増強の必要性有無を検討した。その結果，サーバ機器を計画どおりに増強すると，（ア）自家発の供給電力が不足することが分かり，自家発の増強を計画した。
2021 年度のサーバ機器増強計画を表 1 に示す。

（2）UPS の停電補償時間の課題
電力会社からの電力供給が一定時間停止した場合，自家発が自動で起動する。自家発の機器故障などで自動起動に失敗した場合は，FM 部の担当者が自家発を手動で起動する必要がある。2018 年に自家発を設置したとき，“電力会社からの電力供給停止から，自家発を手動で切り替えて電力の供給が開始されるまでの時間”（以下，自家発切替え時間という）を測定したところ，測定結果は 5 分であった。
UPS は，電力負荷機器の消費電力及び自家発切替え時間を基に選定した。ここで，1kW の消費電力の電力負荷機器には，1.25kVA の出力容量の UPS が必要であるとして検討した。選定の結果，UPS-A，UPS-B，UPS-C，UPS-D 及び UPS-E の 5 台は，UPS タイプ①の UPS を，UPS-F 及び UPS-G の 2 台は，UPS タイプ②の UPS の採用を決定し，設置した。それぞれのタイプ別の停電補償時間は，表 2，3 のとおりである。


2020 年 2 月に自家発の手動起動のテストを実施したところ，FM 部担当者によっては手動起動に最大 20 分掛かることが分かった。FM 部は，自家発切替え時間の短縮を目的に FM 部担当者の訓練を行うこととした。同時に，UPS の停電補償時間に問題がないかを確認するために，表 1 の 2021 年度のサーバ機器増強計画どおりに機器を増強した場合の必要な停電補償時間を 20 分とする条件で検討した。そこで，予備の UPS 機器を除いた UPS-A，UPS-B，UPS-E，UPS-F を対象に検討した結果，これらの UPS では，（イ）必要な停電補償時間を満たさなくなる時期が来ることから，FM 部は，UPS 更新計画を策定することとした。
W 社は，電子機器部品にセンサや通信モジュールを取り付けることで，リアルタイムで稼働状況データを収集する IoT システム（以下，T システムという）を 2022 年 4 月に稼働させることになった。T システムのサーバ機器は複数必要であり，ラック 1 及びラック 3 に分散して収容する。T システムが求める高い可用性を実現するために，UPS の冗長性を強化することとした。そこで，メンテナンスなどで一方の UPS を停止したときに，他方の UPS で障害が発生したときに備えて，電力供給を継続するために，（ウ）予備の UPS を 1 台増設することを計画した。
FM 部では，空調機で障害が発生した場合は，表 4 に示す空調機停止時の影響度判定と対応に従って，対応を行うこととしている。

2020 年 10 月 11 日 23 時頃，ラック 1 内の温度が上昇し，ラック 1 に収容されている，社内向けの勤怠管理システムを運用するサーバ（以下，サーバ 1 という）が停止した。勤怠管理システムを使ったサービスは，10 月 11 日 0 時から 10 月 12 日 8 時までが計画停止時間帯であったので，サーバ停止による業務への影響は発生しなかった。
今回のラック 1 内の温度上昇は，電力会社からの電力供給で瞬断が発生し，空調機 1 が停止したことが原因であった。空調機 2 は保守作業中で使用できず，空調機 1 の正常性確認を行ったことで再稼働するまで 50 分掛かったので，ラック 1 の温度が上昇した。幸い，停止したサーバはサーバ 1 だけであった。10 月 11 日 22 時 30 分に発生した空調機障害の対応経緯を，表 5 に示す。

10 月 12 日 8:00 に勤怠管理システムのオンライン処理が開始しなかったのは，前日の 23:00 にサーバ 1 が停止した際に発生したファイルの内容に関する不具合が原因であった。勤怠管理システムの担当者の Y 氏は，10 月 12 日 8:00 に出社したデータベースの技術者に異常終了について相談した結果，サーバ停止の状況によってはファイルの内容に不具合が発生することがあることを伝えられ，原因が判明し，復旧対応を行った。
FM 部は，空調機 2 の保守作業中に空調機 1 が停止したことは大きな問題と捉え，（エ）空調機停止の再発防止策を検討することとなった。また，表 5 の対応を振り返り，サーバ停止を検知した時点で，関係者を巻き込んで組織的な対応を行うべきであったことから，今後は影響度を高として対応することとし，（オ）表 4 の判定基準を見直すことにした。