オープン・ソース・ソリューションの実装方法:Officeを構築する
このシリーズはオープン・ソース・ソリューションを構築するための基盤を築き上げ、いくつかのソリューションを実装する方法を説明してきましたが、本稿では、これらのソリューションをすべて 1 つの包括的な環境にまとめ、それらを構築するためのヒントやアイデアを提供します。
貴方が、Bob's Bells and Baubles という仮想の会社で働いていると想像してみましょう。Bob は思い切ってその IT 環境全体をオープン・ソース・ソリューションに移行することに決めました (実際にそうした会社がいくつかあるのです)。Bob は考えを重ねた後、次のような機能セットを実装しようとしました。
- 集中型ファイル・サーバー
- 集中型認証サーバー
- Domain Name Service、DHCP などのネットワーク・インフラストラクチャー・サービス
- Eメール配信
- Eメール・フィルター
- ファイアウォール保護
- 在庫キオスク
- インターネット・プレゼンス
さらに Bob には、上記の機能でサポートする必要がある固有の要件があります。
- ファイル・サーバーは、ユーザー・ストレージの自動バックアップをサポートしなければならない。
- 認証サーバーは、ネットワーク・リソースへの認証アクセスをサポートしなければならない。
- 認証サーバーは、ローカル・クライアント・リソースへの認証アクセスをサポートしなければならない。
- ワークロード・プラットフォームは、迅速かつ簡単に追加配備できなければならない。
- ストレージの拡張は簡単でなければならない。
- 配備されたソリューションは可用性が高くなければならない。
- (ファイル・サービスなど) インターネット機能は、 (Web ブラウザーなど) 外部ユーザーからアクセスできないようにしなければならない。
最後に、Bob これらのソリューションを自分の IBM i システムに実装しようとしています。会社では、バックエンド処理と E メール配信には引き続き IBM i を使用する予定です。
実装の計画を立てる
新しい、あるいはアップグレードした環境を始める場合、計画はおそらくもっとも重要な作業になるでしょう。経験から言えるのですが、きちんと計画されていなかった環境は大きな問題につながることが多いのです。迅速な (というより省略された) 計画で「節約した」時間は、実装の段階で無駄になることが少なくありません。
この記事では、当然ですがソリューションの基盤に Linux を使用しているため、 Linux パーティションを 1 つ以上構築する必要があります。まず、Bob の機能要件を確認してから、それらを固有のオープン・ソース・ソリューションにマップします (図 1)。
最初の決め事の中で、Linux LPAR をいくつ実装するかというものがありました。これについてはさまざまな考え方があります。ざっくばらんに言えば、Linux ならばこれらの機能をすべて 1 つのインスタンスでホストできるため、1 つのパーティションで実装を立ち上げることができます。しかし、1 つのパーティションでは、実際に外部アクセスそれぞれと、内部機能およびデータを分離するのは難しそうな気がします。次に考えたのは、提供されている機能ごとに 1 つずつ、複数の Linux パーティションで立ち上げるということです。しかし、その場合 Bob の実装では、 Linux パーティションが 7 つ必要になります。小さなショップが管理するには数が多いのです。お勧めするアプローチは、似たような機能をグループ化しながら、外部および内部アクセスのニーズを考慮する方法です。この例では、次のようなパーティションを実装します。
- パーティション 1: ファイル・サーバー
- パーティション 2: インフラストラクチャー・サービス、Eメール配信、Eメール・フィルター
- パーティション 3: ファイアウォール保護、Web サーバー
- パーティション 4: 在庫キオスク
機能面の類似性と接続要件を、パーティション分割の基盤としました。例えば、インフラストラクチャー・サービスに、E メール配信と E メール・フィルターを加えました。これらはすべて、業務の基本的で核となる機能であり、内部機能であるためです。同様に、ファイアウォール保護と Web サーバーを、同じグループにしました。両方とも外側を向いたネットワークが必要なためです。
次に決定した設計はネットワーク関連です。特に、仮想イーサネット・アダプターと物理アダプターの割り当てです。繰り返しますが、外部および内部アクセスの分離がこれを後押しします。Bob の場合、Web サーバーに外側を向いたネットワーク接続、またファイル・サーバー、ネットワーク・インフラストラクチャー・サービス、E メール・フィルター、キオスク機能に、内側を向いたネットワーク接続を持たせたいと考えています。ファイアウォールには、外部と内部 1 つずつ、 2 つの接続が必要になります。図 2：ネットワーク構成 にこの実装のネットワーク設計を示します。
これは極めて単純なネットワーク構成で、ファイアウォール保護を提供しているパーティションに外側を向いたネットワーク接続だけでなく、内向きの接続もあります。また、Power System 内の 1 つの仮想イーサネット LAN が、すべてのパーティションを接続しています。この 1 つのファイアウォールで、外部ネットワーク接続から保護されていることを覚えておいてください。アプリケーションまたは機能の通信内で、事業アプリケーションに影響を与えるような悪意あるアクションが依然発生するおそれがあります。非武装地帯 (DMZ) を組み込むことで、よりセキュアなネットワーク構成を構築できます (図 3：DMZ によるネットワーク構成)。
最後に、複数の仮想 LAN およびファイアウォールを追加で使用して、機能ベースのデータ通信をさらに分離することで、さらにセキュアなネットワーク構成を構築できます。例えば、ファイアウォール・パーティションとファイル・サーバー・パーティションおよびインフラストラクチャー・サービス・パーティション間で、仮想 LAN/DMZ を構築できます。2 つ目の仮想 LAN/DMZ は、ファイアウォール・パーティションと在庫キオスク・パーティションを接続し、3 つ目の仮想 LAN/DMZ はファイアウォール・パーティションと事業アプリケーションを接続します。
環境を立ち上げる
環境を立ち上げる場合は、以下の作業を網羅します。
- 論理区画の定義
- 仮想入出力の IBM i サポートの構成
- Linux のインストールと構成
- オープン・ソース・アプリケーションのインストールと構成
「オープンソース・ソリューションを実装する方法：Linuxの基盤を構築する」で、論理区画の定義と Linux のインストールについて詳しく説明しましたので、ここではいくつかポイントだけ重点的にお話しします。まず、Linux ベースのワークロードは、 Power Systems の仮想化テクノロジーの大きな活用対象です。通常、Linux パーティションは共有プロセッサーで構築され、パーティションに割り当てられるプロセッサーは最大プロセッサー未満です。また、このシリーズで説明した種類のワークロードについては、パーティションのメモリーとして 2GB 以下が割り当てられる場合が少なくありません。
Linux ワークロードでしばしば活用される、その他の仮想化テクノロジーは仮想入出力です。仮想ストレージでは、複数の仮想ディスクを使用して、簡単に拡張できるよう仮想ディスクを構成することで、オペレーティング・システムとデータを分離しておくことをお勧めします。「オープンソース・ソリューションを実装する方法：Linuxの基盤を構築する」で、論理ボリューム・マネージャーを使用して、ストレージを柔軟かつ拡張可能にする方法をざっとお話ししました。別のアプローチとして、ファイル・システムが常駐する基礎となるディスクのサイズを変更することで、ファイル・システムのサイズを変更する方法があります。仮想ストレージを使用して、またストレージのサイズを変更できることで、ストレージを簡単に拡張するという Bob の要件が満たされます。
IBM i の仮想入出力で見逃しがちな面として、Linux パーティションに光デバイスとテープ・デバイスを割り当て、使用できることがあります。これにより、必要な物理デバイスの数を減らすことができます。しかし、正しく構成されていない場合、システム全体の機能を損なうおそれがあります。説明させてください。仮想ストレージを Linux パーティションに割り当てるには、ネットワーク・サーバーと Network Server Storage Space (NWSSTG) を定義し、ストレージ・スペースをネットワーク・サーバーにリンク設定する必要があります。ネットワーク・サーバーの定義には、Linux パーティションに接続されたリソース (仮想 SCSI サーバー・アダプター) の定義も含まれます。この定義により実質的に、仮想 SCSI バスが作成され、それが Linux パーティションにアタッチされます。仮想ディスクをネットワーク・サーバーにリンク設定すると、ディスクが仮想 SCSI バスに挿入され、Linux パーティションから「見える」ようになります。その結果生じる、リンクされたストレージ・スペースを備えた仮想 SCSI バスは図 4：ディスク専用仮想 SCSI バス のようになります。
ここで見落としがちな点があります。図 4：ディスク専用仮想 SCSI バス は未完成です。ネットワーク・サーバー記述のデフォルト構成は、IBM i パーティションにより認識されている (つまり、割り当てられている) すべての光デバイスおよびテープ・デバイスが、 Linux パーティションに割り当てられます。これは実質的に、ホスティングしている IBM i パーティションに光デバイスおよびテープ・デバイスがある場合、結果生じる仮想 SCSI バスは図 5：光デバイスおよびテープ・デバイスを備えた仮想 SCSI バス のようになるということです。
以下の点を覚えておいてください。
- 光デバイスは、IBM i 上の基礎となるデバイスが ON に変わるときのみ、LPAR で動作している Linux インスタンスに対して使用できます。
- テープ・デバイスは、IBM i 上の基礎となるデバイスが OFF に変わるときのみ、LPAR で動作している Linux インスタンスに対して使用できます。
- Linux がテープ・デバイスを使用すると、そのテープ・デバイスは (on fail になるなど) IBM i パーティションに対して使用できなくなります。
- 基礎となる IBM i デバイスが、実 (物理) デバイスか仮想デバイスかは関係ありません。デフォルトでは依然、Linux パーティションに割り当てられています。つまり、どの仮想光デバイスまたはテープ・デバイスでも Linux で使用できるということです。
お話ししたように、光デバイスとテープ・デバイスはネットワーク・サーバー経由で割り当てられているため、ネットワーク・サーバー記述の定義で割り当てを制御できます。具体的には、Restricted Device Resources (RSTDDEVRSC) パラメーターを設定します。デフォルト設定は *NONE で、すべてのデバイスが割り当てられています。デバイス名をパラメーターで指定することで、特定のデバイスを省略できます。すべての光デバイスは *ALLOPT から省略でき、すべてのテープ・デバイスは *ALLTAP から省略できます。最後に、すべての光デバイスとテープ・デバイスは *ALL を使用して省略できます。
最後に、Linux LPAR を立ち上げるとき、オペレーティング・システムを複数回インストールするのではなく、Linux インスタンスをレプリケートする場合に、仮想入出力機能を活用するようにしてください。Bob のケースでは、Linux を 1 回だけインストールし、オペレーティング・システムをインストールしたストレージ・スペースを単純にコピーするだけで、構成中の他の 4 つのインスタンスを簡単に起動することができます。新しくコピーしたインスタンスを最初に起動する場合、識別情報 (ネットワーク・アドレス、システム名など) を変更する必要がある点を忘れないでください。Linux インスタンスのレプリケート手順については、「オープンソース・ソリューションを実装する方法：Linuxの基盤を構築する」をご覧ください。インストールされた Linux インスタンスをレプリケートする機能により、ワークロード・プラットフォームを迅速かつ簡単に追加配備するという Bob の要件が満たされます。
ソリューションを構築する
LPAR を構成し、Linux をインストールしたら、次はソリューション自体をインストールして構成します。ソリューションの構成方法は皆さんが既に詳しくご存知なので、繰り返し説明することは避けます。ただし、このステップを簡単に行ういくつかのアイデアを重点的に取り上げ、展開しているアプリケーションが、 Bob の要件をいくつか満たす方法を説明したいと思います。
仮想光デバイスを利用して、仮想イメージ・カタログを Linux で使用できるようにすることができる点を忘れないでください。物理インストール・メディアを探す必要がないため、これにより、プログラムとユーティリティーのインストールが簡単になります。また、複数の物理 Power サーバーが Linux をサポートしている場合、イメージ・カタログを Linux イメージで一度ロードアップし、それをシステム間でコピーします。
Bob の認証要件を満たすため、ファイル・サーバー (Samba) を構成できます。ファイル・サーバーについて「オープンソース・ソリューションを実装する方法：ファイル・サービス」で説明したとおり、Samba は既存の認証サーバーに認証するよう構成するか、認証サーバーとして構成することができます。今回は、後者が求めるケースです。Samba ファイル・サーバーがクライアント・ワークステーションを認証するには、Samba の構成ファイルで定義された同じワークグループを指定する必要がある点を忘れないでください。さらに、ユーザーのストレージがクライアントでローカライズされるのではなく、サーバーで集中型になるよう、ホーム・ディレクトリーを共有するために Samba 構成ファイルの [homes] セクションを構成します。
ユーザーのホーム・ディレクトリーがファイル・サーバーに格納されると、「オープンソース・ソリューションを実装する方法：ファイル・サービス」でお話しした postexec コマンドを使用して、ユーザー・ストレージの自動バックアップに関する Bob の要件を満たすことができます。メモリーをリフレッシュするには、以下のコマンドを Samba 構成ファイルの [homes] 定義に配置します。
1 root postexec = tar -cfz /var/samba/backup/%u/%T.tar.gz /home/%u
ユーザーのホーム・ディレクトリーの内容は、ユーザー (%u 変数) にちなんだサブディレクトリー中の /var/samba/backup ディレクトリーの、日時を含むファイルに (tar ファイルで) バックアップされます (%T 変数)。このバックアップはまだローカル・ストレージにあり、FTP または NFS の Linux サポートからテープ、DVD、またはリモート・サーバーなどの外部メディアに書き込む必要があります。
Bob も、新しい環境でのソリューションの可用性を高くしたいと考えています。Linux Virtual Server Project (LVS) のコンポーネントを使用して、 Linux クラスターを構築する方法がありますが、ここでは実践的な例をざっとお話ししたいと思います。真の高可用性を実現するには、物理サーバーとストレージを分ける必要がある点を覚えておいてください。しかし、Linux ソリューションを高可用性にするため、依然として LVS を使用できます。Linux クラスターは、着信サービス要求を受信し、それらを 1 つ以上のサービス・ノードに請け負わせるディレクター・コンポーネントを実装します。ネットワークの観点から、ディレクター・ノードは、顧客が要求するノードを「見える」ようにします。私の例では、図 6 ：クラスタリングによるネットワーク構成はクラスタリングを組み込むよう変更された Bob のネットワーク図を示しています。
ディレクター機能をファイアウォール・パーティションに組み込みました。また、ディレクター機能をそれ自身のパーティションに分割し、クラスターをそれ自身のネットワークに完全に隔離できます (図 7：分離クラスターによるネットワーク構成)。
投資を保護する
どんな IT 投資でも同じですが、Bob の環境のデータを保護することが大切です。ソリューションを設計する際、 rsync や DRBD などのデータ・レプリケーション・ツールが役立つことを覚えておいてください。例えば、上記のクラスター・ソリューションでは、DRBD を使用して Web サーバー間でデータをレプリケートできます。
データの保護に加えて、常に最新の修正および拡張機能をアプリケーションに適用しておくのが良いでしょう。オープン・ソース・スペースは、以下に示すようなこれらのアップデートのさまざまなソースを提供しています。
- Linux ディストリビューション・サービス・パック
- Linux ディストリビューション Web サイト (個々の修正が利用できるようになった時に迅速にアクセスするため)
- アプリケーション・プロバイダー (オープン・ソースでスポンサーされた Web サイト)
Linux ディストリビューターからアップデートを入手したいと考えています。ディストリビューターでは、私が使用している Linux ディストリビューション内で、アプリケーション修正があらかじめテストされるためです。これにより、アプリケーション・プロバイダーからアップデートを入手することで得られる品質保証が高まります。また、ディストリビューターは、アップデート・プロセスを簡略化するツール (SuSE の場合は YaST、RedHat の場合は redhat-update) をディストリビューションに同梱しています。
最後のヒント、触り、考え
最後に、オープン・ソース・ソリューションの扱いで役に立ちそうな、いくつかの項目をお話ししたいと思います。特に、ファイル・システムのセキュリティーについて、ざっと寸評を記述したいと思います。ファイル・システム・セキュリティーの基本は、3 つのユーザー・クラスの 3 セットの権限を解決します。権限とは、読み取り、書き込み、実行の 3 つで、ユーザー・クラスとは、ファイル・オーナー、ファイル・グループ、全員の 3 つです。セキュリティーは、アクセス中のファイルに対するユーザーの関係に基づいて実施されます。例えば、そのユーザーがファイルのオーナーの場合、オーナー権限の資格があり、グループと他の権限は無視されます。ユーザーがオーナーでなく、グループのメンバーである場合、グループ権限が適用されます。最後に、ユーザーがオーナーでもグループのメンバーでもない場合、他の権限が適用されます。
グループのあるメンバーのみ、あるファイルへのアクセスを許可するといった環境など、このレベルのファイル・システム・セキュリティーでは十分でないケースがあります。Linux ファイル・システムは、アクセス・コントロール・リスト (ACL) をサポートします。このリストでは、ファイルのセキュリティーをよりきめ細かく定義できます。
Linux オペレーティング・システムの概念は、単純なコマンドを豊富に提供し、シェル・スクリプトの使用によりユーザーが、それらをさまざまなソリューション向けに構築できるようにすることです。Linux のシェル・スクリプトは、IBM i の CL または、Windows/MS-DOS システムのバッチ・ファイルに似た機能を提供するものと考えることができます。
最後に、Linux には、バックアップなどのタスクに使用できる cron というジョブ・スケジューラーがあることを忘れてはなりません。分、時間、日、月、曜日という 5 つのパラメーターに基づいてジョブをスケジューリングできます。
