４つのモードで選ぶOES2

OES2 (Open Enterprise Server 2)を構成するには次の４つの構成があります。

1) Native NetWare 6.5
2) SLES10 + XEN + NetWare 6.5
3) SLES10 + XEN + OES2 Linux
4) OES2 Linux

仮想化という選択肢が増えたことにより、さまざまな形態の運用が可能になりました。それぞれの、メリットとデメリットを考えて見ましょう。


1) Native NetWare6.5

これはもちろん従来の NetWare をそのまま使う方法です。

メリット
・安定して枯れていて、高速である
・ディスクストライプを有効に使える
・従来の資源をそのまま利用できる
・従来のスキルセットがそのまま利用できる。
・大規模データの運用が可能
・admin のパスワード管理が容易

デメリット
・将来のハードウェア対応、ソフトウェア対応が未知数
・慣れたエンジニア、運用メンバーの不足、育成が課題

2) SLES10 + XEN + NetWare 6.5
この構成は SLES10 上に XEN 仮想化された NetWare を準仮想化モードで運用するものです。

メリット
・Linux のスキルセットを身につけられる
・小規模なデータ量ならバックアップ、リストアが容易
・システム丸ごとのバックアップができる


デメリット
・低速、低パフォーマンス
・大規模なディスク構成が難しい
・従来のスキルセット + SUSE Linux + XEN の知識が必要
・eDirectory のadmin パスワードと root のパスワードを別に管理しなければならない。

SLES XEN NetWare という三題話ができなければこの構成はできません。


3) SLES10 + XEN + OES2 Linux

メリット
・全て Linux のスキルセットで実施できる
・システム丸ごとのバックアップ、リストアが容易

デメリット
・低速、低パフォーマンス
・大規模な構成が難しい
・eDirectory のスキルセットが必須
・いくつかの重要なツールが不足している
・eDirectory のadmin パスワードと root のパスワードを別に管理しなければならない。共有パスワードになり易い。

4) OES2 Linux

メリット
・Linux のスキルセットで運用できる
・将来のハードウェア、ソフトウェアのサポートが期待できる

デメリット
・ディスクストライプは有効に使えない
・eDirectory のスキルセットは必須
・現在の安定性、サポート、性能に関しては未知数
・いくつかの重要なツールが不足している
・情報、運用実績の欠如
・eDirectory のadmin パスワードと root のパスワードを別に管理しなければならない。共有パスワードになり易い。


-安定性、安全性
安定性、安全性という視点で捉えると 1) Native NetWare が現時点で最高の選択肢であることは言うまでもないでしょう。従来の NetWare の資源がそのまま利用できるし、すでに NetWare 6.5 のライセンスを持っているのであれば、特にライセンスコストがかかるわけでもありません。バックアップや無停電装置などとの連携も実績があるものばかりです。
過去のインターフェースそのままですから、なんの不安もなく移行できるはずです。

また、OES2 Linux は /,/Boot のパーティションを持つディスクと、NSSのボリュームを持つパーティションは別な論理ディスクにしなければならないという（強い推奨）制限があるため、中小規模のサーバとしては破綻なく Raid 5 構成をとることができます。

ただし、若い運用担当者は Linux に関する知識を持ちたいと願うことが多いでしょう。近年のハードウェアでは、NetWare に関する動作検証やドライバの提供がない場合もありますし、Linux なら何とかなるが NetWare に関する知識が一切ないＳＩベンダーも多いため、自己責任できるなら、現時点では最高でしょう。NetWare に関してならば、Novell のサポートサイトに豊富な情報があります。

ただし、ファイルサーバ＋GroupWise兼プリントサーバといった使い方であれば、プリントサーバの部分だけでも XEN + NetWare 化したいところです。Native NetWare は純粋にファイルサーバや GroupWise のPOA として利用することが良いでしょう。

この場合、iPrint, LDAP, ZENworks,GroupWise MTA, GWIA あるいは FTP, ディレクトリレプリカ、ＣＡルートなどの軽くて、遅延がユーザに影響のないシステム、また設定が複雑で壊れ易い、あるいは再起動を頻繁にしたいようなシステムは XEN 化すべきです。SLES上で XEN カーネルで動作させれば、samba や HTTP, メールのリレーなどにも使えますから選択肢はさまざまです。

-将来性、多様性
今後のハードウェエアの進化やドライバの提供情況を考えると OES2 Linux という選択肢になります。ただし、この構成は EVMS の制限から、ブートシステムと、ＮＳＳの論理ディスクをわけなければならないという問題があり、例えば２Ｕで８ドライブのシステムだと、２ドライブでルートを作り、残り６つでＮＳＳを構成するようなシステムにしなければなりません。したがって中小規模で容量を稼ぎたいシステムではちょっと中途半端で苦しいかもしれませんね。
かといって、１Ｕ２ドライブでルートを作り、外部ストレージで数テラバイトのシステムも可能ですが、そこまで予算や必要性、バックアップの時間の問題などさまざまな問題が出てきそうです。

また、バックアップや日本語ファイルに関する問題はまだ未知数なので、自己責任でどこまでバックアップ、リストアができるかという問題もあります。

それでも１台だけでの運用は避けた方が良いので OES2 Linux + SLES + XEN + OE2(NetWare または Linux)での平行運用をお勧めしたいところです。

OES2 Linux だけでは ZENworks などの全ての機能が使いきれません。また、OES2 にはいくつか便利なＤＯＳコマンド類が抜けているので SLES + XEN + NetWare の環境がある方が融通は利きます。

それでも NetWare のスキルセットが全くない情況であれば OES2 と XEN 環境との組み合わせも仕方がないでしょう。これだけなら Linux のスキルセット + eDirectory の運用により高度な運用が可能になります。iManager のシステムは、実行速度に問題がありそうですが、バグが多いので XEN 化した上で利用するのが良いでしょう。Samba でファイル共有なら数人でも構わなくても、拠点数が多く、コンプライアンスや運用の最適化をするのであれば Open Ldap + Samba などの運用より、よほど効果のある運用が可能です。

--
いずれにせよ XEN 上で OES2 (NetWare, Linux) を動かすには意外とリソースが必要です。HTTP 程度のサービスであれば 384M 程度のメモリでも十分ですが、OES を XEN 仮想化するには 1G 以上のメモリを仮想メモリとして割り当てるべきですので、実用性を考えるとたとえ１Ｕサーバでも４Ｇ以上のメモリを搭載した、デュアルコア、クアッドコアのシステムを検討すべきです。また、XEN 仮想化すると、そのコンピュータの上で Windows XP や Windows 2003 のシステムも動作するということを覚えておけば、かなり柔軟な構成が可能なはずです。

全てのシステムを SLES + XEN + OES2 という構成にするのは夢の世界です。XEN についてはディスクやネットワークのＩ／Ｏが弱いという致命的な欠点があるので、別に iSCSI のサーバを検討するなど、構成上弱点が多く存在するシステムになりますから、ネットワークやストレージを二重化、ファイバ化するなどの工夫が必要です。そうなるとデータセンター運用を前提とした、相当大規模な運用形態になるので、そこまでは私が語るレベルではありません。

現実には、システム部や周囲のバックオフィスでメンテナンスが容易な部分では OES2 Linux を、補助システムとして SLES + XEN を、全社のクリティカルなシステムは Native NetWare を利用するというのが、今の時点での最高の組み合わせです。

キーワード
OES SUSE Linux eDirecrory LDAP NSS NetWare

続きはこちらで
非番のエンジニア