MECM/SCCM導入事例～キッセイコムテック株式会社様～その3
前回は、レンタルPCの多種多様なバリエーションに容易に対応するために、どのような対策を行ったかご紹介しました。
キッセイコムテック様が抱える非常に悩ましい課題を、SCCM で解決するためには様々な対策が必要でした。
今回は、当日レンタルでも確実に納品できるようにシステム障害で業務を止めない対策をご紹介します。
クリアすべき課題
MICEのお仕事では納期がとてもシビアです。お客様は短い時間で開催準備を進めています。そんな中、「システム障害で納品が半日遅れます」なんて許されません。
いつ、どこで、どんなシステム障害が起きても、納期を確実に守るためにも業務を継続できる環境づくりが必要です。
そこで、各種サーバの冗長化を行うことにしました。どちらかで障害が起きても、もう片方で業務を続けられるようにします。
冗長化といっても、コールドスタンバイのように切替に時間がかかっては意味がありません。そもそもうまく起動するとも限りませんし、スタンバイ側を常に最新の状態にする方法を考える必要もあります。よってボツです。
大事な時に限ってうまく起動しないものです。
ActiveDirectoryサーバ
ActiveDirectory のドメインコントローラは、複数サーバ間で容易に冗長化することができます。
2台目以降のドメインコントローラを作ると、設定にも依りますがプライマリサーバから2台目以降のサーバへ自動でデータが「複製」されます。
レプリケーションと呼びます。
今回はプライマリサーバとセカンダリサーバの2台構成としました。
障害が起きた場合
もし片方のサーバで障害が起きた場合、もう片方が使用されますので、業務が止まることはありません。
SCCMサーバ のプライマリサイト・管理ポイント
SCCM サーバのプライマリサイト・管理ポイントは、SCCM の中心となる役割です。
これも冗長化することができます。
まず SCCM サーバに「中央管理サイト」と呼ばれるサイトの親玉の役割を与えます。そしてこのサーバに「プライマリサイト」の役割を持つ SCCM サーバを複数ぶら下げます。
このような構成にすることで、あるプライマリサイトサーバへ変更を加えると、中央管理サイトサーバ経由で他のプライマリサイトサーバへデータが同期されます。
例えば、あるパッケージを登録してしばらくすると、全てのプライマリサイトサーバにパッケージが登録されます。
今回は2つのプライマリサイトをぶら下げました。
もちろんプライマリサイトのサイトコードはそれぞれ異なります。
2種類のタスクシーケンスメディア
タスクシーケンスメディアとは、キッティングするPCに挿すブートメディアのことです。今回はUSBメモリを使いました。
タスクシーケンスメディアには、アクセスするプライマリサイトのサイトコードが登録されています。
もし一方のプライマリサイトに障害が発生した場合、もう一方のプライマリサイトへアクセスするタスクシーケンスメディアを使います。よって業務が止まることはありません。
中央管理サイトに障害が起きたら
中央管理サイトは、各プライマリサイトの同期を行っているだけです。キッティングに必要なデータを保持しているわけではありませんので、業務が止まることはありません。
もちろんそのまま放置するわけにはいきませんので、業務と並行して復旧させる必要はあります。
余談ですが、もし中央管理サイトが止まった状態で新たにパッケージを作成しても問題はありません。
パッケージはパッケージIDで一意に管理されています。パッケージIDの上3桁はパッケージを作成したサイトのサイトコードです。
よってパッケージ作成後に中央管理サイトが復旧し同期が始まっても、パッケージIDが重複することは無いのです。
SCCMサーバの配布ポイント
SCCM サーバの配布ポイントは、各種パッケージファイルを保持する役割を持ちます。キッティングされるPCは、配布ポイントからファイルをダウンロードします。
配布ポイントに関しては単純に2つ用意しました。配布はどちらに対しても行います。プライマリサイトが2つありますが、どちらからも配布されるイメージです。よって2つの配布ポイントの中身は常に同じです。
どの配布ポイントからでもダウンロードできるようにするためには
キッティングされるPCからは、どちらの配布ポイントからでもダウンロードできるようにしました。どちらからもダウンロードできるようにするためにはちょっとしたコツがいります。
各配布ポイントには境界グループと呼ばれるIPアドレス群が割り当てられています。境界グループに含まれているIPアドレスを持つPCに対してのみファイルのダウンロードを許す仕組みになっています。
2つの配布ポイントに同じ境界グループを割り当てることで、どちらからもダウンロードできるようになります。
障害が起きた場合
特に何もしなくてOKです。
どの配布ポイントからダウンロードするかは、プライマリサイト・管理ポイントが判断し、クライアントPCに指示を出します。障害が起きた時点で使用できない配布ポイントと判断されますので、もう一方の配布ポイントからダウンロードされるようになります。
最後に
各種サーバを様々な方法で冗長化することで、障害時でも SCCM を止めずに済みます。
ただ、SCCM の一般的な用途でここまで対応するケースは少ないと思います。SCCM の主な役割はクライアントPCの管理（各種プログラムの配布や状態の把握）ですので、 障害で止まってもまず業務に影響を与えることはないのです。
たいていは定期的なバックアップで事足ります。
今回は SCCM によるキッティングが”業務”そのものですので、障害時に止まらないようにする必要がありました。
次回は、ストレージ不足への対策についてご紹介します。