オープンソースの OpenStack クラウド・オペレーティング・システムは、あらゆるタイプのクラウド・コンピューティングに対応する、充実した機能と高いスケーラビリティーを備えたプラットフォームです。いくつかのパブリック・クラウド・サービスは、OpenStack をベースとしています。同様に、多くの組織内部のプライベート・クラウド実装にも OpenStack がベースとして使用されていますが、OpenStack のプライベート・クラウド向け機能は、まだ十分に揃っているとは言えません。特に開発用の環境やテスト用の環境となると、十分ではありません。そのため、一例を挙げると、イメージを作成するプロセスが単純でなかったりします。そこで、この記事では OpenStack プライベート・クラウド用のイメージを作成するための新しい改善された方法を提案します。私たちはこの新しい方法を QEMU/KVM プラットフォームで検証しましたが、理論上は、他のハイパーバイザー・プラットフォームにもこの方法を適用することができます。
新しい方法を紹介する前に、現在 OpenStack ではどのようにイメージが作成されるのか、その概要を説明します。
OpenStack でイメージを作成する現在の方法
OpenStack で Linux または Windows のイメージを作成するプロセスには、時間がかかるステップが複数あります。
Linux ベースのイメージ
公式の「OpenStack Virtual Machine Image Guide」では、OpenStack クラウドで Linux ベースのイメージを完全に機能させるために満たさなければならない 7 つの要件を詳しく説明しています (そのうちのいくつかの条件は、cloud-init パッケージをインストールして満たすことができます)。このイメージ・ガイドでは、使用しようとしている OpenStack の機能を確実にサポートするイメージを作成するには、これらの要件について詳しく説明しているセクションを読むよう、ユーザーにアドバイスしています。
Linux イメージは、特定のディストリビューションに対応した VMBuilder、Oz、imagefactory などのツールを使用して作成することも、自ら手作業で作成することもできます。どの方法を使用するかに関わらず、独自の Linux イメージを作成するには、以下のものが用意されていなければなりません。
- OS インストール CD/DVD、または ISO イメージ・ファイル
- KVM/QEMU ハイパーバイザーが有効にされている Linux マシン (ディストリビューションによっては、
virt-manager/virt-viewerGUI ユーティリティーが必要です) - OS に対応した
cloud-initまたは同等の自作のスクリプト - イメージを変更するためのユーティリティー (
guestfish、guestmount、virt-*などのツール)
必要条件がすべて満たされると、以下に要約するステップに従って、独自の Linux イメージの作成を開始することができます。
virt-managerまたはvirt-installを使用して、仮想マシン (VM) を作成し、OS をインストールします。- ユーザーそれぞれの要件を満たすように OS を構成し (例えば、必要なミドルウェアをインストールするなど)、
cloud-initまたは同等のスクリプトをインストールして OpenStack の要件を満たします。 guestfish、guestmount、またはvirt-*を使用して、OpenStack の要件を満たすようにイメージを変更します。- 新しく作成したイメージを OpenStack イメージ・サービスにアップロードして、イメージを検証します。
Windows ベースのイメージ
OpenStack の Webサイトには、Windows ベースのイメージを作成する詳細な例は、まだ記載されていません。ただし、作成する Windows ベースのイメージが完全に機能するには、少なくとも以下の作業を行う必要があります。
- VirtIO ドライバーをインストールします。
- RDP (Remote Desktop Protocol) を有効にして、ファイアウォールを通過するように構成します。
- ファイアウォールを通過するように ICMP (Internet Control Message Protocol) を構成します。
- ディスクをパーティション化して、ブートのルート・パーティションをサイズ変更します (
cloudbase-initを使用)。 - ユーザー・データとその他のメタデータを処理します (
cloudbase-initを使用)。 - Windows のシステム準備ツール (Sysprep) を有効にして、ゲスト OS をカスタマイズできるようにします。
プライベート・クラウドを使用するほとんどのケースでは、上記最後の 2 つの要件はオプションです。またブート時に (スクリプトを使用するか、手作業で) ディスクをパーティション化したり、ルート・パーティションのサイズを変更したりすることができます。ただし、OpenStack クラウドで Windows イメージを機能させるには、VirtIO ドライバーをインストールする必要があります。さらに、VirtIO-Win ドライバー・パッケージを入手する必要もあります。
最小要件を満たした後、Windows イメージを作成するプロセスは、以下のとおりです。
- IDE (Integrated Drive Electronics) ディスクと AMD li>net32 または Realtek rt8139 ネットワーク・インターフェース・カード (NIC) を使用して VM を作成します。
- OS をインストールします。
- ユーザーそれぞれの要件を満たすように OS を構成し (例えば、必要なミドルウェアをインストールするなど)、
cloudbase-initまたは同等のスクリプトをインストールして OpenStack の要件を満たします。 - VM をシャットダウンします。
- 小さいサイズの VirtIO ディスクと VirtIO NIC を追加します。
- VM を起動して、VirtIO ディスク用と VirtIO NIC 用の VirtIO ドライバーをインストールします。
- VMを再起動して、OS を確認してから VM をシャットダウンします。
- 作成したイメージを Oli>nStack イメージ・サービスにアップロードして、イメージを検証します。
あるいは、以下の手順に従うこともできます。
- 以下の構成要素を使用して VM を作成します。
- VirtIO ディスク
- PCnet32 または rt8139 NIC
- VirtIO ディスク・ドライバー追加用 CD-ROM (Windows Vista 以降、または Windows Server 2008 以降の Windows の場合)、または VirtIO ディスク・ドライバー追加用フロッピー (Windows Server 2003 R2 やそれ以前の Windows の場合)
- 必要な VirtIO ディスク・ドライバーと一緒に OS をインストールします。
- ユーザーそれぞれの要件を満たすように OS を構成し (例えば、必要なミドルウェアをインストールするなど)、
cloudbase-initをインストールするか、同等のスクリプトを実行して、OpenStack の要件を満たします。 - VM をシャットダウンします。
- VirtIO NIC を追加します。
- VM を起動して、VirtIO NIC 用の VirtIO ドライバーをインストールします。
- VMを再起動して、OS を確認してから VM をシャットダウンします。
- 作成したイメージを OpenStack イメージ・サービスにアップロードして、イメージを検証します。
欠点
OpenStack 用のイメージを作成する現在の方法は、いくつかの利点はあるものの (例えば、Linux ベースのイメージを作成する際に、さまざまなオープンソース・ツールを利用できます)、簡単ではありません。Windowsベースのイメージを作成する場合は、guestfish などのツールを使ってイメージを変更する必要がないため、Linux イメージを作成するプロセスよりも多少簡単なように思えますが、現時点では、OpenStack 用の完全な機能を備えた Windows ベースのイメージを作成するための自動化ツールはありません。従って、エンド・ユーザーまたはオペレーターがそのようなツールを自らの手で作成する必要があります。グローバリゼーション・チームのテスターまたは開発者が Windows イメージを必要とする場合、Windows イメージは言語ごとに異なるものでなければなりませんが、チームが何十もの言語を使用しているとなると、要求されたすべての言語の Windows イメージを用意するのは、クラウド・オペレーターにとっては不可能なことでしょう。
Linux イメージにしても、Windows イメージにしても、プライベート・クラウド用のイメージを作成するのは、時間がかかる作業となります。これは、エンド・ユーザーが作成する場合にのみ言えることではなく、経験を積んだクラウド・オペレーターが作成する場合にも言えることです。さらに、エンド・ユーザーがイメージを作成するために必要なリソースが組織にないことも考えられます (例えば、Linux イメージの作成に必要な追加の KVM/QEMU ハイパーバイザーなど)。そのような状況では、エンド・ユーザーから要求されたすべてのイメージを作成するのは、クラウド・オペレーターにとって相当な負担がかかります。
しかも、新しいイメージを OpenStack イメージ・サービスにアップロードする必要もあります。イメージ・ソースと OpenStack イメージ・サービスとの間のネットワークのパフォーマンスによっては、このプロセスにかなりの時間がかかります。同じ理由から、新しいイメージを繰り返し検証するのにも、かなりの時間がかかることがあります。
OpenStack イメージを作成する方法として新たに提案する方法
OpenStack のユーザーがオンラインでイメージを作成できるようになれば、ユーザーは今までより遥かに簡単に、それぞれのニーズを満たすイメージを作成することができます。私たちは、イメージを作成する新たな方法として、クラウド・サービスが提供する OpenStack ダッシュボードを使用して、ユーザーが新しいイメージをオンラインで作成する方法を提案します。この方法でイメージを作成できれば、エンド・ユーザーが追加のハイパーバイザーを必要とすることも、作成したイメージを自分で OpenStack イメージ・サービスにアップロードする必要もなくなります。この場合、必要なのは OS インストール CD/DVD ISO イメージ・ファイルだけです。
概念設計
概念的には、エンド・ユーザーが以下の作業を行うことが OpenStack 用の新しいイメージを作成する理想的なプロセスとなります。
- OS インストール用 CD/DVD ISO イメージ・ファイルを OpenStack イメージ・サービスにアップロードします。
- アップロードした ISO イメージから新規インスタンスを起動します。
- OpenStack ダッシュボードの VNC (Virtual Networking Computing)/SPICE (Simple Protocol for Independent Computing Environments) コンソールから、OS をインストールします。
- 特殊なニーズに応じて必要な構成を行い、必須のソフトウェア・パッケージをインストールします。
- OpenStack が必要とする変更を手作業で加えるか、サービス・オペレーターが提供するスクリプトを実行します (例えば、
cloud-initをインストールするスクリプト、公開 SSH 鍵を取得するスクリプト、SSHD リモート・ログイン/RDP を有効にするスクリプト、等々)。 - インスタンスのスナップショットを取ります。
- 必要に応じて、スナップショットに対して
glance image-updateコマンドを実行して、スナップショットをイメージに変換して他のメタデータを追加します。
前提条件
この新しいイメージ作成方法を成功させるには、以下の条件を満たす必要があります。
- 実際に使えるダッシュボードまたは Web UI が、すべてのエンド・ユーザーに利用可能になっていること。
- VNC プロキシーまたは SPICE プロキシーが正常に機能し、すべてのエンド・ユーザーに利用可能になっていること。
cloud-initまたは同等のスクリプト・ツールのリポジトリーが、すべてのエンド・ユーザーに利用可能になっていること。- VirtIO-win ドライバーの ISO イメージが OpenStack イメージ・サービスにあり、すべてのエンド・ユーザーに利用可能になっていること。
次は、この新しい方法の実現可能性を実際の例で示します。
実現可能性の調査
この新しい方法の最も重要な 2 つの側面は、ISO イメージをサポートする方法と、ISO イメージから起動されるインスタンス用にブロック・デバイスをアセンブルする方法です。
現在の ISO イメージのサポート
ISO イメージは、OpenStack でサポートされています。ISO イメージからのインスタンスの起動もサポートされていますが、ISO イメージに含まれるゲスト OS を ISO イメージから起動されたインスタンスにインストールするという部分に関しては、十分にサポートされていません。以下の厳しい条件が満たされていなければ、インストールは成功しません。
- ISO イメージに含まれるゲスト OS の VirtIO デバイス・ドライバーが、デフォルトで有効にされること。
- 一時ディスクのフレーバー (仮想ハードウェア・テンプレート) が設定されていて、そのサイズがゲスト OS の要件を満たすこと。
- ダッシュボードと OpenStack novncproxy サーバーが正常に稼働中であること。
上記のすべての条件が満たされていれば、ISO イメージに含まれるゲスト OS を、この ISO イメージから起動されたインスタンスの一時ディスクに正常にインストールすることができます。もちろん、他のインスタンスの場合と同じく、ゲスト OS の下で作業することもできます。しかし、OpenStack の現在のインスタンス・スナップショット・メカニズムでは、インスタンスを正常にインスタンス・スナップショットまたはイメージに変換することはできません。変換したとしても、インスタンス・スナップショットに含まれるのはインスタンスのルート・ディスクだけで、一時ディスクやボリュームなどの他のブロック・デバイスは無視されてしまいます。
インスタンス・ブロック・デバイス用の現在のアセンブリー・ワークフロー
図 1 に、ISO イメージから KVM/QEMU インスタンスをブートする際の OpenStack Nova でのブロック・デバイスのアセンブリー・ワークフローを示します。
図 1. ブロック・デバイスをアセンブルするための現在のワークフロー
図 1 のワークフローでは、以下の処理が行われます。
- Nova が Glance から ISO イメージを取得し、この ISO イメージを VM インスタンスのルート・ディスクとして設定し、デバイス・タイプとして CD-ROM を、バス・タイプとして IDE を設定します。
- Nova が一時ディスクを作成し、この一時ディスクを VM インスタンスの 2 番目のディスクとして設定し、デバイス・タイプとしてディスクを、バス・タイプとして VirtIO を設定します。ただし、このステップが行われるのは、一時ディスクのサイズがインスタンスのフレーバーに設定されている場合のみです。
- ユーザーがルート・ディスク (インスタンスの CD-ROM) に含まれるゲスト OS を一時ディスク (インスタンスの 2 番目のディスク) にインストールして、VNC を使用してステップバイステップでゲスト OS を構成します。
- ユーザーがこの VM インスタンスからスナップショットを作成し、Nova がそのスナップショットを Glance サービスに保存します。
このワークフローは、新しい VM イメージを一から作成するには有効なように思えますが、このワークフローで取得されるイメージは、元の ISO イメージのコピーです。その理由は、スナップショットに含まれるのはルート・ディスク (インスタンスの最初のブロック・デバイス。つまり実際には、インスタンスが ISO イメージから起動された場合はインスタンスの CD-ROM) だけで、一時ディスクは無視されるためです。従って、現在の OpenStack では、ISO イメージからインスタンスを起動して、一時ディスクが構成された起動済みインスタンスに、ISO イメージに含まれる OS をインストールすることは可能ですが、OS がインストールされた一時ディスクのスナップショットを取ることはできません。この問題に対処するには、インスタンスのブロック・デバイスのアセンブリー・ワークフローを調整する必要があります。
新たに提案するアセンブリー・ワークフロー
適切なサイズに設定された一時ディスクを作成し、その一時ディスクが必ず ISO イメージから起動されたインスタンスのルート・ディスクとして設定されるように、ブロック・デバイスのアセンブリーを変更することができます。このように変更した後、インスタンス・スナップショットに含まれるルート・ディスクは、まさに目的どおり、OS がインストールされた一時ディスクになります。
図 2 に、libvirt ドライバーに変更を加えた後 (これについては、この記事の「概念実証」のセクションで説明)、ISO イメージからインスタンスをブートした場合のブロック・デバイスのアセンブリー・ワークフローを示します。
図 2. ブロック・デバイスをアセンブルするための変更後のワークフロー
以下に、ISO イメージからインスタンスを起動する際のブロック・デバイスのアセンブリー・ワークフローを変更する方法を記載します。
- Nova が VM ディスク・ファイルを作成し、これを VM インスタンスのルート・ディスクとして設定します。デバイス・バスは、デフォルトで VirtIO に設定されます。
- Nova が、Glance からゲスト OS の ISO イメージを取得し、これを 2 番目のディスク・デバイス (CD-ROM) として設定します。
- Nova が、Glance から VirtIO ドライバーの ISO イメージを取得し、これを 3 番目のディスク・デバイス (別の CD-ROM) として設定します。
- ユーザーが、2 番目のディスク・デバイス (最初の CD-ROM) からゲスト OS をインストールし、必要に応じて構成します。
- VirtIO ドライバーがデフォルトでゲスト OS に含まれない場合は、3 番目のディスク・デバイス (2 番目の CD-ROM) を使用してゲスト OS 用の VirtIO ドライバーをインストールします。
- ユーザーがこのインスタンスのスナップショットを作成し、Nova がそのスナップショットを Glance サービスに保存します。
「現在の ISO イメージのサポート」で説明したように、インスタンス・スナップショットに含まれるのは、ルート・ディスクのタイプに関わらず、インスタンスのルート・ディスクだけです。変更後のアセンブリー・ワークフローでは、ルート・ディスクは Nova によって作成された新しいディスク・ファイルになります。このファイルには、OS イメージである CD-ROM (インスタンスの 2 番目のディスク) からインストールされたゲスト OS が含まれます。
私たちが考えたとおり、最終的な結果は、元の ISO イメージのコピーではなく、OS ISO イメージからインストールされた新規インスタンスのインスタンス・スナップショットになります。
概念実証
この新しいイメージ作成方法が、私たちが設計したとおりに機能することを確実にするために、Nova コード (主に libvirt ドライバー) にいくつかの変更を加えました。関連するコードを入手するには、「ダウンロード」を参照してください。変更した Python モジュールは、libvirt/driver.py と libvirt/blockinfo.py です。これらのファイルには、変更したクラス・メソッドとインスタンス・メソッドを見分けられるように、コメントを追加しておきました。
概念実証に使用した環境は、以下の構成要素からなります。
ハードウェア:
- 2 U ラック・サーバー
- 4 コア Xeon プロセッサー (x2)
- 8GB の RAM (x12):
- RAID10 が構成された 900GB の SAS ハード・ディスク (x4)
- 1Gps Ethernet カード (x4)
ソフトウェア:
- Red Hat Enterprise Linux 6 アップデート 4 (ハイパーバイザーとして使用)
- RDO Grizzly リリース
変更したコードを、RDO Grizzly のオールインワン環境、RDO Grizzly のマルチノード・インストール済み環境、および公式 OpenStack Grizzly リリースのそれぞれでテストしました。
テストの実行と結果
このセクションでは、単純なテスト・プロセスについて説明し、この新しい方法で VM イメージを作成するために変更後の Nova を使用して実行したテストの例を記載します。
テスト・プロセス
テスト・プロセスは以下のとおりです。
- Glance に応じた OS ISO イメージを作成します。
- 既存のフレーバーを調べて、ルート・ディスクのサイズが望みどおりのサイズであることを確認します。該当するフレーバーがない場合は、新しいフレーバーを作成します。
- 該当するフレーバーで、この OS ISO イメージからインスタンスを起動します。
- インスタンスが起動したら、ダッシュボードの VNC コンソールで、画面上のインストール手順に従って OS のインストールを完了します。
- 必要に応じてアプリケーションをインストールし、OpenStack の要件に従って OS を構成します (
cloud-initまたは同等のスクリプトのインストール、SSHD リモート・ログイン/RDP サービスの有効化など)。 - この新しくインストールしたインスタンスのスナップショットを作成します。
- スナップショット情報を更新してイメージ・タイプをイメージに変更するために、
glance image-updateを実行するか、ダッシュボードから (ダッシュボードに該当する機能が提供されている場合) この作業を行います。
テスト結果
libvirt ドライバーに変更を加えた後の、ISO イメージから起動したインスタンスのブロック・デバイスはリスト 1 に示すとおりです。
リスト 1. ISO イメージから起動したインスタンスのブロック・デバイス・マッピング
<disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='none'/> <source file='/var/lib/nova/instances/290124e3-a267-4223-bd69-661fac2035eb/disk.newos'/> <target dev='vda' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </disk> <disk type='file' device='cdrom'> <driver name='qemu' type='qcow2' cache='none'/> <source file='/var/lib/nova/instances/290124e3-a267-4223-bd69-661fac2035eb/disk'/> <target dev='hda' bus='ide'/> <readonly/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> <disk type='file' device='cdrom'> <driver name='qemu' type='qcow2' cache='none'/> <source file='/var/lib/nova/instances/290124e3-a267-4223-bd69-661fac2035eb/disk.virtio'/> <target dev='hdb' bus='ide'/> <readonly/> <address type='drive' controller='0' bus='0' target='0' unit='1'/> </disk>
表 1 に、複数のメインストリーム OS でのテスト結果を記載します。
表 1. テスト結果
| ゲスト OS | 結果 |
|---|---|
| Windows XP | 失敗* |
| Windows Server 2003 R2 | 失敗* |
| Windows 7 | 成功 |
| Windows 8 | 成功 |
| Windows Server 2012 | 成功 |
| RHEL5.9 | 成功 |
| RHEL6.4 | 成功 |
| SLES10 sp4 | 成功 |
| SLES11 sp3 | 成功 |
| *注: Windows XP と Windows Server 2003 R2 でのテストが失敗した理由は、VirtIO ドライバーのフロッピー・ディスクが見つからなかったためです。その根本原因は、Windows Server 2003 R2 またはそれ以前の Windows では、フロッピー・ディスクからの追加ディスク・ドライバーのロードしかサポートされないことにあります。この記事では、図 2 に示されているように VirtIO ドライバー追加用 CD-ROM だけを追加していますが、古いバージョンの Windows の場合には、ブロック・デバイスのアセンブリー・ワークフローにさらにフロッピー・ドライバーを追加することもできます。 | |
まとめ
この記事で紹介した、イメージを作成する新しい方法には、以下の利点があります。
- OpenStack 用の新規イメージを簡単に作成することができます。
- 新しく作成されたイメージを簡単に検証することができます。
- すべてのエンド・ユーザーが、セルフサービス・メカニズムを利用できます。
欠点としては、以下の点が挙げられます。
- イメージで一部の機能 (特に、ディスクのパーティション化と、ブート時のルート・パーティションのサイズ変更) がサポートされない可能性があります。
- Windows Server 2003 R2 またはそれより古いバージョンの Windows Server はサポートされません (ただし、アセンブリー・ワークフローをもっと複雑にして、フロッピー・ドライバーをサポートするようにすれば、古いバージョンの Windows をサポートできるようになります)。
- VirtIO デバイス・ドライバーをサポートしていない古いバージョンの Linux はサポートされません。
これまでのところ、ほとんどの OpenStack ベースのパブリック IaaS クラウド・サービスでは、ベース・イメージの中に固定サイズのルート・ディスクを備えたインスタンスと、(ボリューム・サービスを通じた) そのインスタンス用の追加ディスク・スペースを提供しています。プライベート・クラウドの場合、インスタンスに関する要件の大部分は、インストールするミドルウェア、ゲスト OS のバージョン/エディション、インスタンス・フレーバーなどに焦点を置いたものです。ディスク・サイズの要件は、パブリック・クラウド・サービスの場合と同じく、固定の平均ルート・ディスク・サイズと十分なボリュームを提供すれば満たすことができます。従って、ほとんどのプライベート・クラウドでは、ディスクをパーティション化して、ブート時にルート・パーティションをサイズ変更できることは必須になりません。
OpenStack は、オープソースのクラウド・オペレーティング・システムのグローバル・プラットフォームとして高い評判を得るまでに成長しました。OpenStack を使用すると、各種のクラウド・ソリューションは、高いスケーラビリティーと豊富な機能を備えたものとして、簡単に実装できるようになります。私たちがこの記事で説明した作業が、OpenStack プラットフォームをベースに新しい機能を実装できること、そして OpenStack は単なるソフトウェア製品ではなく、オープンで柔軟なフレームワークであることを証明しています。
ダウンロード
| 内容 | ファイル名 | サイズ |
|---|---|---|
| Sample code | sample_code.zip | 39KB |
参考文献
学ぶために
- 「OpenStack について学ぶ」: (John Rhoton 著、developerWorks、2014年2月): この複数の記事からなる連載で、OpenStack に関するすべてを学んでください。
- 以下の開発者リソースを通じて OpenStack システムについて詳しく調べてください。
- OpenStack Compute (Nova):
- Image Services (Glance):
- OpenStack Storage (Swift)
- OpenStack のドキュメント:
- developerWorks における OpenStack の Wiki: OpenStack の Wiki で情報を共有してください。
- RDO: RDO は、Red Hat Enterprise Linux、Fedora、およびそれらから派生したディストリビューション用の OpenStack 実装です。
- クラウド開発者向けリソースを提供している developerWorks のサイトで、クラウドにデプロイするためのプロジェクトを構築している、アプリケーションおよびサービスの開発者の知識と経験を見つけて共有してください。
製品や技術を入手するために
- IBM 製品の評価版をダウンロードして、DB2、Lotus、Rational、Tivoli、WebSphere が提供するアプリケーション開発ツールやミドルウェア製品を試してみてください。
議論するために
- developerWorks コミュニティーに参加してください。ここでは他の developerWorks ユーザーとのつながりを持てる他、開発者によるブログ、フォーラム、グループ、Wiki を調べることができます。
コメント
IBM PureSystems
IBM がどのように IT に革命をもたらしているのかをご自身でお確かめください
Knowledge path
developerWorks の Knowledge path シリーズでは、テーマ別の学習資料をご提供しています
ソフトウェア評価版: ダウンロード
developerWorksでIBM製品をお試しください！