読者です 読者をやめる 読者になる 読者になる

Taste of Tech Topics

Acroquest Technology株式会社のエンジニアが書く技術ブログ

OpenStack Ironic用のカスタムイメージファイルを作る【導入編】

OpenStack クラウド基盤

こんにちは、こんばんは、miyakeです :-)

先日の4/7(木)に、OpenStackのMitakaが正式リリースされました :-)
去年のカンファレンスで表明された機能がどこまで実現できているかなどなど、気になっているところです ;-) 多分、近いうちにMitakaを調べ始めることになると思います :-)

話変わって、ここ最近、プロジェクトでOpenStackのIronicを使用したベアメタルクラウド環境の開発や構築をやっているのですが、まだまだ発展途上にあるIronicを使って実運用システムの開発を進めていると、未知の問題やソースコードを読まないと解決しない問題などなど、色々な問題にハマっては解決してきました。
その色々ハマった問題のうちの一つである、Ironic用カスタムイメージファイルの生成手順について、今回と次回の二回に分けて書いてみます。

今回は【導入編】として、Ironicの簡単な説明と、ronic用カスタムイメージファイルの基になる、仮想マシンディスクイメージファイルの作成手順とハマりどころについて説明します。
次回は【Ironic用イメージファイル生成編】として、今回作成する仮想ディスクイメージファイルから、Ironic用イメージファイルを生成する手順について説明する予定です :-)

Ironicって?

f:id:acro-engineer:20160409181126p:plain
Ironicは、OpenStackのベアメタル用コンポーネントのプロダクト名称で、OpenStack Kiloから正式に採用されるようになったコンポーネントです。

本家のIronic概要説明 >> Introduction to Ironic

Ironicが使えるようになる前までは、計算リソースとしてVM(仮想マシン)しか扱えなかったOpenStackですが、Ironicを導入することで、ベアメタルサーバ(物理サーバマシン)を計算リソースとして扱えるようになります。
仮想マシンでは性能要求を満たせないケースや、ハードウェアの機能を直接使用したいケースの問題を解決することが可能になります。
※ケースとして通信性能の限界まで使い切りたいNFVとかGPUを使いたい場合などが考えられます。PCIパススルーで解決できるものもありますが、そこまでするなら物理サーバマシンを利用した方が便利なケースが増えてくるだろうな...と思っています。

Kiloから正式に採用されたとはいえ、NovaやKeystoneのAPI仕様のバージョンアップ時期とも重なっていたせいか、APIバージョンのミスマッチなどもあり、Kiloの次のLibertyから何とか使えるようになった...というのが私の認識です。

Libertyからまともに使えるようになったように書いていますが、Liberty時点のNeutronでは仮想マシン用の仮想ネットワーク機能しかできないため、物理サーバマシンのネットワーク制御については、OpenStackだけでは実現できないという大きな課題が残っています。
この課題があるため、Libertyでは仮想マシンと物理サーバマシンを、Neutronで管理するでネットワークセグメント内で通信させることができません。
※仮想ネットワークにかなりの制限を付けたうえで、フレーバーとかを上手く使えば、なんとか共存出来そうな気はしますが...
次のMitakaで対応する...と宣言されていますが、対応Switchが限定されているため、物理サーバマシンのネットワーク制御については、当分の間は自前で実現することになると思っています...多分物理サーバマシン間のネットワーク制御までで、仮想マシンとの接続はできないか、VLANでセグメントを分離する方式にしか対応できないだろうと思います。
※実際うちのプロジェクトでは、OpenFlowスイッチで物理サーバマシンのネットワーク制御を行うコンポーネントを開発して使っています

Ironicで使用するイメージファイルの種類

Ironicでベアメタルサーバを使えるようにするためには、ベアメタルサーバにインストールする、OSを含めたディスクイメージを用意する必要があります。

このディスクイメージには、大きく分けて「デプロイ用イメージ」「インストール用イメージ」の2種類が必要になります。

概要は、以下のページのシーケンス図に説明されています。

CHAPTER 1. INSTALL AND CONFIGURE OPENSTACK BARE METAL PROVISIONING (IRONIC)
https://access.redhat.com/webassets/avalon/d/Red_Hat_Enterprise_Linux_OpenStack_Platform-7-Bare_Metal_Provisioning-en-US/images/PXE_Provisioning.png

ざっくり説明すると、
シーケンスの"Send a DHCP request"~"Sends the deploy kernel and ramdisk"「デプロイ用ディスクイメージ」をPXEBootを使ってベアメタルサーバに転送して実行し、「インストール用ディスクイメージ」をddコマンドでディスクに書き込めるよう、iSCSIで書き込める準備を行います。
準備ができた通知をIronicが受けると、シーケンスのConnects to the iSCSI endpointインストール用ディスクイメージを書き込みに行きます。
このあと再起動を行い、インストールしたイメージでベアメタルサーバが起動します。

そのようなわけで、Ironicで使用するイメージディスクはに、「デプロイ用ディスクイメージ」「インストール用ディスクイメージ」の2種類を作成する必要があります。
今回の記事の対象となる「Ironic用カスタムイメージファイル」は、「インストール用ディスクイメージ」になります。

ちなみにIronicのイメージファイルの考え方は、V2Pが前提になっています。
V2PとはVirtual to Physicalのことで、仮想マシンディスクイメージを物理マシンにデプロイするという意味になります。
VMにだけ対応していたころのOpenStackであれば、V2V(Virtual to Virtual)だけできていればよかったのですが、ベアメタルサーバに対応する必要があるため、このV2Pに対応する必要が出てきました。

※現時点のIronicではP2P(Physical to Physical)ができません。実運用システムでIronicを使用することを考えると、物理マシンイメージのスナップショット取得やスナップショットからの復旧ができないため、いくつかの運用上の制限が出てきます...これもIronicの課題の一つかなぁ...と思っています

今回は、このV2Pに対応したIronic用イメージファイルの基になる、仮想マシンディスクイメージファイルを作成する際の注意点について説明しています。

仮想マシンディスクイメージファイルの生成

前置きが長くなってしまいましたが、Ironic用カスタムイメージファイルの基になる、仮想マシンディスクイメージファイルの生成手順の説明に入ります。
今回の説明では、CentOS7の仮想マシンディスクイメージの作成手順を説明します。
FedoraなどRedHat系であれば、ほぼそのまま応用ができると思います。
Ubuntuなどについては...すみません...この例を参考にして調べてみてください。

KVMを使って仮想マシンディスクイメージファイル生成

それではまず最初に、Ironic用カスタムイメージファイルの基になる仮想マシンディスクイメージファイルを、ISOイメージから生成します。

まずは以下のコマンドを実行して、KVM仮想マシン上でCentOS7のインストーラを起動してOSをインストールします。
なお、OSの細かいインストールの説明などは省いています。また、ある程度KVMを使ったことがあることを前提とした説明になっています...

# qemu-img create -f qcow2 /var/lib/libvirt/images/centos7-custom.qcow2 10G

# virt-install --virt-type kvm --name centos7-custom --ram 1024 \
  --disk /var/lib/libvirt/images/centos7-custom.qcow2 \
  --network network=default \
  --graphics vnc,listen=0.0.0.0 --noautoconsole \
  --os-type=linux --os-variant=rhel7 \
  --location=/var/lib/libvirt/images/CentOS-7-x86_64-DVD-1511.iso

CnetOS7のISOファイルである、CentOS-7-x86_64-DVD-1511.isoはCnetOSのダウンロードページか、ミラーサイトからwgetなどでダウンロードし、/var/lib/libvirt/images/の下に配置してくださ。
virt-install実行後、仮想マシンが正常に起動すると、VNCクライアントから接続してGUIでインストールできるようになります。VNCクライアントには、UltraVNC Viewerなどを使ってください。(VNCクライアントから接続するためのポートNoは、5900から順番に払い出されます)

で、このインストール時に設定するディスク構成が最初のハマりどころになります。

【ハマりどころ その1】

インストーラでディスク構成を決める際、デフォルト構成のままでインストールすると、Ironic用イメージファイル変換に失敗してしまいます。

理由は、Ironic用イメージファイル変換に使用しているdisk-image-createコマンドの制限のためです。

この制限に引っかからないようにするため、ディスク構成は"/"の1パーティションのみとし、ファイルフォーマットはxfsとして生成し、そこにすべてをインストールするようにしてください。swapパーティションを切りたくなるかもしれませんが、swapパーティションもあると変換時に「swapファイルをマウントできません」という警告が出て変換に失敗します。

仮想マシンディスクイメージファイルからIronic用イメージファイルに変換する際、仮想マシンディスクイメージファイルを変換を行っているマシン上のディスクとしてマウントし、必要なファイルの抽出や変更を行っているのですが、デフォルトのLVM構成や、複数パーティションに分割されたイメージファイルをマウントすることができないため、1パーティションのxfsフォーマットのイメージファイルにする必要があります。

仮想マシンディスクイメージファイル固有の設定

OSインストールが完了したのち、ベアメタルサーバで動作させたいサービスのインストール、設定変更などを行って仮想マシンを構築します。

この際、OpenStackで必要となる、仮想マシンイメージ固有のパッケージインストールや設定変更を行います。

cloud-initのインストールと設定

まずはcloud-initのインストールと設定変更を行います。
cloud-initは、VMを生成する際に、VMのホスト名称やssh接続に使用する公開鍵ファイルの配置などを行うためのパッケージです。
OpenStackは、VM上のcloud-initからの要求を受け付け、ホスト名称設定や公開鍵の配置を行っています。

まずはcloud-initのインストール

# yum -y install cloud-init

インストール後、/etc/cloud/cloud.cfg という定義ファイルが生成されます。
通常は設定変更をする必要はないのですが、デフォルトユーザ名称が"centos"となっています。(CentOSの場合)
"centos"のままだと、なんというか違和感があるので、このデフォルトユーザ名称を変更します。
まず、viで/etc/cloud/cloud.cfgを編集します。

...

system_info:
  default_user:
    name: admin  <-- ここをcentosからadminに変更
    lock_passwd: true

...

この例では、元々"centos"となっていたnameを、"admin"に変更しています。
これで、このイメージから生成されたサーバにsshでログインする際、公開鍵を使って、ここで変更したデフォルトユーザ名称でログインすることができるようになります。

GRUB2定義変更

次はGRUB2の設定に、シリアルコンソール接続のための設定を追加します。
これは、仮想マシンに対してKVMのconsoleコマンドで接続したり、OpenStackが仮想マシンの起動時の出力をログに保存する際に使用しています。よって、ベアメタル向けの場合は必要ないと思われますが、念のため....

まず、viで /etc/default/grub に、コンソールの情報を設定します。

GRUB_CMDLINE_LINUX="console=tty0 crashkernel=auto console=ttyS0,115200"
↓
GRUB_CMDLINE_LINUX="vconsole.keymap=jp106 crashkernel=auto vconsole.font=latarchrheb-sun16 console=tty0 console=ttyS0,115200n8r"

GRUB_CMDLINE_LINUXの設定を、上のように変更します。

変更した後、grub2-mkconfigコマンドで、実際のGRUB2定義ファイルを変更します。

# grub2-mkconfig -o /boot/grub2/grub.cfg
zeroconfの無効化

最後に、以下のコマンドを実行してzeroconfを無効化します。

# echo "NOZEROCONF=yes" >> /etc/sysconfig/network

以上で、仮想マシンイメージファイル固有の設定が完了です。
あとは、各自が必要とするパッケージインストールや設定、systemctlでサービスを有効化するなどを行います。

上記が完了したら、shutdownで仮想マシンを終了させます。

Ironic用カスタムイメージ変換前の下準備

KVMで生成した仮想マシンのイメージファイルをIronic用カスタムイメージに変換するため、以下のコマンドを実行して、KVMから切り離すなどの準備を行います。

# virt-sysprep -d centos7-custom
# virsh undefine centos7-custom
# mkdir /root/image
# cp -p /var/lib/libvirt/images/centos7-custom.qcow2 /root/image/.
# cd /root/image

以上で、 仮想マシンディスクイメージファイルの作成は完了です。

次回は、この仮想マシンディスクイメージファイルから、Ironic用カスタムイメージの生成手順について説明します :-)

それではまた~~ :-)

補足事項

  1. Ironicのデプロイの仕組みには、大きく分けて、ddコマンドを使ってディスクイメージを転送するだけの単純なもの(pxe_ipmitool)と、デプロイ先のディスクパーティションをカスタマイズできるAgentを組み込んだもの(agent_ipmitool)の2種類がありますが、今回と次回で説明するイメージファイル作成手順は、ddコマンドでイメージを転送するデプロイ方式向けのイメージファイルの作成方法について説明しています。

Acroquest Technologyでは、キャリア採用を行っています。


  • 日頃勉強している成果を、AWSHadoop、Storm、NoSQL、Elasticsearch、SpringBoot、HTML5/CSS3/JavaScriptといった最新の技術を使ったプロジェクトで発揮したい。
  • 社会貢献性の高いプロジェクトに提案からリリースまで携わりたい。
  • 書籍・雑誌等の執筆や対外的な勉強会の開催を通した技術の発信や、社内勉強会での技術情報共有により、技術的に成長したい。
  • OSSの開発に携わりたい。

 
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。
 
データ分析で国内に新規市場を生み出す新サービス開発者WANTED! - Acroquest Technology株式会社の新卒・インターンシップ - Wantedlywww.wantedly.com