さくらのデータセンターに導入したラック電子錠コントローラの開発物語

公開日

編集部より

さくらインターネットでは、データセンターの物理セキュリティーを強化し、データセンターの無人化を進める取り組みを進めています。その端緒として、ラックの鍵を電子的に開閉できるコントローラを東京エレクトロン デバイス長崎株式会社(TED長崎)と共同開発し、当社の一部データセンターにて運用を開始しました。開発した製品はTED長崎から「RMS-EL128」として発売されています。

この記事は、2023年7月5日(水)に開催した「さくらの夕べ in 長崎」において、TED長崎の西村拓郎さんに「ラック電子錠コントローラ『RMS-EL128』開発物語」と題してご発表いただいた内容を記事化したものです。

参考資料

はじめに

「ラック電子錠コントローラ『RMS-EL128』開発物語」と題しまして、東京エレクトロン デバイス長崎の西村が発表させていただきます。「開発物語」と謳っていますが、事前に社内で発表練習して何人かに聞いてもらったときには「これ物語じゃないよね」とツッコミをいただいてます。その辺はちょっとご容赦ください。

自己紹介と会社紹介

私はこの会社に入社して13年目になります。普段はソフトウェアの開発を担当していますが、ソフトウェアといってもユニットに組み込むようなファームウェアを担当することがほとんどで、インフラとかアプリのことはあまりやっていません。

弊社の紹介も簡単にさせていただきたいと思います。東京エレクトロン デバイス長崎株式会社は、長崎県諫早市に本社があります。長崎市から電車で30分ぐらいのところです。設立は1987年で、私と同い年ですね。スライドの右下に本社の写真があるんですけど、2年前に新社屋になったばかりで、まだとてもきれいです。とても働きやすい環境で仕事させてもらってます。製造上の実装ラインは3ライン保有しています。4D外観検査装置という珍しい装置も用意しています。

弊社の製品も紹介します。大きく分けて、自社開発している製品と受託開発の製品を展開しています。

自社製品の方は、FAXや電話などのCT関連機器がまずあります。それから今回ご紹介するEL128のような、データセンターをターゲットにした遠隔操作の装置や、データセンターの温度や電流などの環境を監視する遠隔監視装置、さらに電源ユニットなどのスマートエネルギー関連製品を3本柱に展開しています。

弊社は製品の企画から開発設計・製造・販売・アフターサービスまで、弊社の方で一貫体制で行っております。製品化までのすべての工程でお客様をサポートできるという点が弊社の強みになっているのかなと思います。

ちなみに、TP2000というCT関連機器があって、色合いがカステラに似てるのでスライドに入れればウケるんじゃないかと思って入れたんですけど、どうでもいいですね(場内笑)。

製品の概要

それでは、RMS-EL128について紹介します。さくらインターネット様と一緒にお仕事させてもらって開発したものになります。製品をよくご存じない方もいっぱいいらっしゃると思うんで、概要をご説明いたします。

製品の目的としては、データセンターにあるラックの電子錠を遠隔から操作できるようにするというシステムになります。製品の概要としては大きく分けて4つのポイントがあります。

  1. まず上位サーバというものがあります。
  2. 次に、RMS-EL128-Mという、スライドの上部にある黒い箱ですね。これを親機と呼んでます。
  3. その隣にあるのが子機と呼んでいるRMS-EL128-Dですね。
  4. 子機からラックに付いている電子錠や温度センサーを監視制御できます。

親機と上位サーバはLANでつながっていて、親機と子機はRS485シリアル通信でつながるものになります。

弊社は親機と子機の製造を担当しました。上位サーバはさくらインターネット様に開発いただきました。上位サーバから指令を出して、それが親機から子機に伝わって鍵の解錠・施錠を行うというシステムなので、基本的には親機と子機だけでは何もできなくて、上位サーバありきのシステムとなります。

スライドの下の方に機器構成を掲載しています。親機から4ライン出ていて、1ラインに接続できる子機が最大32台ですね。1ライン32台で4ラインなのでMAX128台の子機をつなげることができます。EL128という名前もここから来ています。

さくらインターネットからの要求仕様

この製品やシステムを実現するにあたって、さくらインターネット様からいただいた要求は、大きく以下の4点でした。

  1. ラック扉ロックの開閉制御やICカードの読み取りが行えること
  2. ICカードを照合したり開閉指示を出すのは上位サーバが行う
  3. 給電・通信を1本のケーブルで行う
  4. 配線経路長は256ラックで400m、親機より給電

1についてはサウスコ製のドアハンドルを使うことになりました。また、配線経路長に関する指定は、消費電力や通信遅延を考慮して上限を決定しました。最終的には32ラックで200m、それが4系統ということになりました。

ここでの特徴の一つは、給電と通信を1本のケーブルで行うという点ですね。電源を外部から取らずに設置・構成できるところが大きな特徴の一つかなと思います。

このような仕様のやり取りを2018年ぐらいから開始して、製品を開発し完成にこぎつけたということになります。

システム構成の検討

このようなシステムを実現するにあたり、システム構成をどう検討していったかをお話ししたいと思います。

子機はデイジーチェーン接続で構成

親機と子機の構成については、ラック監視システムの既存製品にならって、親機直結の構成をまず提案いたしました。というのも、弊社でも独自の電子錠ユニット製品を展開しておりまして、それはユニット同士を親機直結で接続するというものになっておりますので、弊社の感覚でなじみのあるこの方式をまず提案しました。しかし最終的にはデイジーチェーン接続という形が採用されることになりました。

親機直結接続のメリットとしては、電力供給や親子間通信が容易に行えたり、子機がシンプルになって低コストになることが見込めます。しかし、距離や台数によっては配線量が増えてしまいます。逆にデイジーチェーンの方は、親機コネクターや配線量を減らせるといったメリットがありますが、距離や台数が増えると電圧降下が起きてしまうとか、子機が高機能になって値段が高くなってしまうというデメリットもあります。しかし、ラックの拡張性やメンテナンスのメリットを重視して、デイジーチェーン接続が採用されることになりました。

冗長性の確保

次に冗長性の確保です。親機は1台でも使えるんですけども、2台目の親機(サブ親機)を接続することで冗長性を持たせようとしています。そのサブ親機をどう配置するかも検討しました。こちらはY型配置をまずご提案したんですけども、最終的にはそれではなく両端に親機が配置されることになりました。両側から給電されますので、子機が故障した場合も他の子機を動かしたまま交換作業ができるのが大きなメリットです。メンテナンス性を考慮してこのような構成になりました。

ケーブルや通信について

このシステムで使用するケーブルはPLC方式で、絶縁用インダクタの特注品となりました。つまり汎用のものでは対応できなかったということです。既存部品で組めるDC48V電力2線＋RS485通信2線の4線式を採用しました。必然的にRS485の通信は差動信号の半二重通信ということになりました。

通信の方式については、親機が子機をポーリングする方式ではなく、子機からイベントを通知する方式を基本的な動きにしようということになりました。子機の方で何らかの状態変化を検知したら、子機自身が隣の子機にイベントを投げます。それを隣の子機が受信し、さらに隣の子機にデータを渡すというバケツリレー方式です。この方式は通信に時間を要するため、それが問題なく行えるかも検討しました。

ドアハンドルの仕様変更

ドアハンドルはサウスコ様の特注品を使用いたしました。これは鍵の制御だけでなく、表示LEDの点灯パターンも追加されているものになります。ラックが開いている状態だったら青を点滅させたり、カードを読み取ったら紫を点灯するだとか、状態ごとのLED点灯動作を子機から細かく制御できるようなものになります。

子機からドアハンドルを直接制御することで、子機同士をつないでいるRS485ライン通信を介さずにドアハンドルの反応表示を実現でき、またその制御自体も高速になるように最適化された仕様にしてもらっていますので、即時反応を可能としています。

ここで、サウスコ様との試作品のやり取りが結構発生したんですけども、サウスコ様の開発元は海外なので、サンプルを入手するのにも時間がかかります。期待した動作ではない場合も何回かありまして、そうなった場合の状況相談も、こっちが昼間でも向こうは夜だったりするのでなかなかうまくいかず、さらにできていたと思われたことが次の試作品ではできなくなっていたこともありました。最終的には完成したのでよかったんですけども、ハンドルの制御がうまくいかない場合の原因の絞り込みが非常に大変だったという思い出があります。

システム概要

このような、さまざまな検討を経て完成したシステム構成を図にまとめるとこのような形になります。先ほどから申し上げている通り、上位サーバがあり、冗長化された親機から4本のRS485が出ていて、子機はそのラインごとに最大32台つながるという構成になります。で、子機にはそれぞれ最大2つのカード付き電子錠を付けて、2つのラックを制御できるという形になります。32台×4ラインで128台まで対応できます。

こういう構成なので、子機を交換するときも、通電遮断や復電制御を上位サーバから行えば容易に実施できます。

通信の流れ

ここからはちょっとソフトウェアの話になるんですけども、この構成での通信の流れはどうなっているかっていうのをちょっとご説明したいと思います。

基本的には先ほど申し上げたように、子機からのイベントによって動くシステムとなりますけども、状態取得などでサーバから今どうなっているかを問い合わせることも可能となっています。サーバから特定の子機にリクエストを投げて、その子機が応答をサーバに返すという仕組みです。逆に、ラックのハンドルにICカードがタッチされてカードを読み取った場合は、子機から通知が発信されて上位サーバに通知が行き、上位サーバからは受け取った旨の確認応答を子機に対して戻すという流れになっています。

ここでちょっと考慮しないといけないのは、サーバからの要求と子機からの通知がぶつかってしまう場合もありうるという点です。これの対応としては、確認応答がなければ通知をリトライするという方法を採っています。基本的にはこれでいいんですが、より強固なものにするために、子機同士のデバイス間通信でもデータを再送する仕組みを適用し、それによって通信の正当性を保証するようにしています。具体的には通信データの破損を検出したり、送ったのにACKが来なかったっていうのを待ち受けて、ちゃんとACKが得られるまでもう1回再送するという仕組みを設けています。

通信テスト

次は通信テストです。このような仕組みでちゃんと通信できるかということで、子機が128台、一斉に何かしらのイベントをサーバに通知するという想定でのテストを行いました。実際の運用ではまず起こらないことだと思うんですけども、テストのためということで、そういう環境を用意してテストしました。結果としては、128台の子機が一斉に状態変化を検出し、上位サーバに128台分の通知が行われた場合でも、上位サーバではそういうデータを全部受け取っていて、通知が不足なくちゃんと届くことを確認できました。

逆に上位サーバの方から128台の子機に順次問い合わせた場合も、すべての子機から応答が得られたということで、子機からの応答も不足なく届くことを確認できました。よって、通信品質という意味では良いものができたんじゃないかなと思っております。

通信品質もそうなんですけども、セキュリティ面でも強固な通信を行っています。さくらインターネット様と協議して、通信ルールを独自に定義しています。シリアル上の通信であればModbusとか、イーサネットだったらREST APIとかの利用を思いつくところですが、そういった一般的なプロトコルにも当てはまらないので、内容の推測が困難な通信データとなっています。また、通信の暗号化も実施してまして、秘匿性というのも考慮されています。その分、通信の整合性とかシーケンス処理とか、実装上で配慮する点が多くなったので、こういった通信テストで通信の妥当性を検証したというところになります。

実機での接続評価

実際に評価を行っているところです。写真に映っているのは私で、上位サーバを操作しているところです。実際にさくらインターネット様がデータセンターで運用されるようなちゃんとした上位サーバは作れなかったので、自作したものでテストしました。

大きい写真の手前の方に映っている2つの黒い箱が親機になります。右上の写真はスタックさせた子機です。子機につながってるケーブルを見てもらえばわかりますが、非常に太くて重たいんですね。ですので、ケーブルのテンションで子機が引っ張られて落ちちゃうというようなこともありました。そこで、子機をタワーのようにスタックさせて、下の方はちゃんとネジ止めして固定して、動かないように安全な状態でテストしました。そういった、テストするまでの準備も結構大変でした。さらに、場所もなかったのでみかん箱みたいなものに子機を詰め込んだりもしました。ケーブルもうまく束ねないとすごくかさばるので、束ね方も工夫が必要でした。

電源供給まわり

電源供給まわりも簡単にご紹介しておきます。

電源は1系統あたり最大250W程度を想定してます。想定っていうのは最大どれぐらいかということですが、パワーとしては余裕がある設計になります。4系統あるので、DC48V電源を4個搭載してます。評価時の模擬負荷としてはホーロー抵抗を使用しています。長時間のフル負荷時は扇風機で冷却するような形ですね。ホーロー抵抗を使用したのは、評価の時に大量の子機を持ち歩くのは大変だということで、ホーロー抵抗で代用したという次第です。

新型コロナウイルスの影響

最後になりますけども、コロナの影響についてもお話しします。

2019年末頃から新型コロナウイルス感染症の流行により、世の中のレスポンスが全体的に悪くなりました。このRMS-EL128の開発もちょうどコロナとぶつかってしまい、非常にレスポンスが悪くなって大変でした。あと、コロナの影響で一番大きかったのは、電子部品が不足して部材の調達が困難になったことです。新型コロナウイルスが5類になったことで行動制限は緩和されましたけども、部品が手に入りにくい状態は現在も続いていますので、今後も心配ではあります。

以上で私の発表を終わりたいと思います。ご清聴いただきましてありがとうございました。