Performance Co-Pilotでパフォーマンス測定を簡単にしよう

Red Hat Enterprise Linux 7(そして6.7)にはパフォーマンス監視や記録のために、従来のsysstatなどに加えてPerformance Co-Pilot(PCP)が含まれました。PCPは特に複数台からなる大規模なシステムのパフォーマンス監視に便利な特長を多くもっています。今回はPCPをご紹介します。

レッドハットの森若です。Red Hat Enterprise Linux 7(そして6.7)にはパフォーマンス監視や記録のために、従来のsysstatなどに加えてPerformance Co-Pilot(PCP)が含まれました。

PCPは2000年にSGIがIRIX用に出荷してから現在まで15年ほどの歴史があリ、特に複数台からなる大規模なシステムのパフォーマンス監視に便利な特長を多くもっています。

Performance Co-Pilot(PCP)とは?

Performance Co-PilotはCPU使用率やディスクアクセスなどのパフォーマンスメトリクスを収集、分析するためのフレームワークです。データ収集のためのデーモンと、さまざまな形で出力するためのクライアントが提供されています。

PCPのアーキテクチャはデータ収集をするデーモンとクライアントにわかれています。クライアントはローカルホストだけでなく、リモートサーバへの接続ができるので、リモート環境や複数台からなる環境のパフォーマンス監視をごく自然におこなうことができます。

データ収集デーモンには、収集をおこないクライアントからの接続を受けつけるpmcdと、実際に測定対象からパフォーマンスデータを収集するpmdaの2種類のプログラムが登場します。pmdaは測定対象ごとに、kernel, linux, cisco, mounts, などのコンポーネントに分かれていて必要なものだけを選択して利用します。pmdaはユーザが新しく作成して拡張することもできます。

 

PCPの名前空間

PCPであつかうメトリクスは名前、データ型、単位の組み合わせで定義されており、名前はツリー状の構造を持っています。たとえばCPUの使用量であれば、kernel.percpu.cpu.user のようにPMDAの名前からはじまり、順に分類が細かくなっていきます。現在のシステムで利用可能な測定値の名前一覧はpminfoコマンドで取得できます。

各項目の説明はpminfo -t で、現在の値はpminfo -fで取得できます。各項目には複数のインスタンスを持つことができるので、たとえばディスク性能の項目についてはパーティション毎などのインスタンスが含まれます。以下はpminfoで項目の意味と値や単位を確認する例です。

$ pminfo -dtf disk.partitions.read

disk.partitions.read [read operations metric for storage partitions]
    Data Type: 32-bit unsigned int  InDom: 60.10 0xf00000a
    Semantics: counter  Units: count
    inst [0 or "sdb1"] value 29668
    inst [1 or "sda1"] value 257
    inst [2 or "sda2"] value 2
    inst [3 or "sda5"] value 120259
    inst [4 or "sr0"] value 0
    inst [5 or "sdc1"] value 358

特殊な項目としてハードウェアインベントリhinvがあり、この項目はCPU数やメモリの総量など基本的に変化しないメトリクスを保持します。

PCPのクライアント

PCPではあらかじめ様々な種類のクライアントが用意されています。クライアントの一部を眺めてみましょう。

GUIでグラフを作成するpmchart

vmstat風の出力を出してくれるpmstat

top風の出力をおこなうpmatop

オプションのクエリにしたがって任意のメトリクスを定期的に表示するpmval

トリガの設定とコマンド実行

クライアントの1つであるpmieでは専用の言語によりメトリクスを使った各種の条件でトリガーを設定し、コマンド実行やログ出力を行います。pmieconfコマンドであらかじめ用意されたテンプレートをカスタマイズしてpmieの設定を作成することもできます。

以下はpmieconfが生成する設定の例です。2分おきに測定し、ネットワークインタフェースのどれか1つでも帯域利用率が85%を越えていれば利用率とインタフェースをログに出力します。1度出力を行うと10分間は警告の出力を抑制します。

delta = 2 min;
per_netif.util =
some_inst (
    ( 100 * network.interface.total.bytes   /
       network.interface.baudrate   )
          > 85
    && network.interface.baudrate   > 0
) -> syslog 10 min "High network interface utilization" " %v%util[%i]@%h";

PCPのアーカイブ

PCPはsarとおなじように定期的に測定したパフォーマンスメトリクスをアーカイブへ保存することができます。クライアントとして実装されたpmloggerがアーカイブを作成します。それぞれのメトリクス毎にアーカイブへ記録する頻度を設定でき、たとえばCPU使用率は30秒ごとに、ディスク使用率は10分ごとに記録するような設定が可能です。pmloggerもリモート接続が可能なので、測定対象のサーバ上でもデータ収集用のサーバでも実行できます。

sarのアーカイブでは残念ながらバージョンやアーキテクチャによる非互換がありますが、PCPのアーカイブはOSやアーキテクチャから独立したフォーマットが策定されています。さらにPCPのバージョンからも独立しており、ドキュメントによれば15年前に保存されたアーカイブであっても最新版のPCPで問題なく読み込むことができるとのことです。このような特徴があるため、複数のバージョンやOSが混在している環境のパフォーマンス監視にも活躍します。

クライアントライブラリはリアルタイムの情報収集とアーカイブ参照の両方に対応しているので、ほとんどのクライアントはリアルタイムの確認と過去データのリプレイのどちらにも対応しています。過去のデータも現在のデータと同じように確認できるため、現在の性能と過去の性能を比較するような作業が容易になります。

他プログラムとの連携

PCPでは各種言語のライブラリが整備されており、たとえばLinuxサーバやDockerの管理インタフェースとしてRHEL7.1から導入されたcockpitも性能情報はPCP経由で取得しているなど、他のプログラムからの利用が容易になっています。ベンチマークなどで高度な分析をおこないたい場合にも、アーカイブをPythonなどのプログラムから読み込むことで様々な活用が可能となります。

関連情報

  • man PCPIntro

Red Hat Enterprise Linuxでの独自コンテナイメージの作成

Docker上で動作するコンテナイメージは『docker-buildコマンド』と、『Dockerfile』を作成することで、カスタマイズして作成することができます。 今回は、この2つを使って簡単なコンテナイメージを作成してみようと思います。

独自コンテナイメージの作成

サイオステクノロジー杉崎です。
前回は、「Red Hat Enterprise LinuxでのDocker利用方法」の中で、Dockerって何?という記事を書かせていただきました。今回は、さらに一歩進めた内容で、Dockerを紹介をさせていただきます。

Dockerfileの作成

『Dockerfile』に必要な内容を記述することで独自のコンテナイメージを作成することができます。
それでは、最低限の記述でコンテナイメージを作成してみましょう。
『Dockerfile』に、以下の内容を記述するだけで、doucker-buildコマンドは実行することができます。

# cat Dockerfile
From centos
MAINTAINER test<test@test.com>

《From centos》で、利用するコンテナイメージとして《CentOS》を選択したことになります。
《From fedora》した場合《fedora》を選択したことになります。
「MAINTAINER test<test@test.com>』 で、作成するコンテナイメージの管理者を設定します。

コンテナイメージを作成

コンテナを作成するときには、『docker-buildコマンド』を使用します。
簡単にイメージを作成するには、以下のパラメータのみで作成することができます。

 # docker build -t [ {イメージ名} [ : {タグ名} ] ] {Dockerfileのあるディレクトリ}

それでは、実際にdocker-buildを使ってみましょう。実行例の様に入力し”Enter”を押してみましょう。

# docker build -t centos-test .
Sending build context to Docker daemon 12.29 kB
Sending build context to Docker daemon 
Step 0 : FROM centos
    == snip ==
Status: Downloaded newer image for docker.io/centos:latest
 ---> 7322fbe74aa5
Step 1 : MAINTAINER test<test@test.com>
 ---> Running in 97c22992c485
 ---> ad6a0dee9cda
Removing intermediate container 97c22992c485
Successfully built ad6a0dee9cda

Successfully built 〜 が出力されたことから、『docker-buildコマンド』を利用してのコンテナイメージの作成は成功したことになります。

では、『docker-imagesコマンド』を使って、ローカルに作成されたコンテナイメージの結果を見てみましょう。

# docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
centos-test         latest              ad6a0dee9cda        About an hour ago   172.2 MB
docker.io/centos    latest              7322fbe74aa5        5 weeks ago         172.2 MB

実行結果から、centos-testが作成されていることが確認できます。

コンテナイメージの起動

コンテナイメージを起動してみましょう。
起動コマンドに使用するコマンドは、docker-runコマンドになります。
簡単にイメージを起動するには、以下のパラメータのみで作成することができます。

 # docker run -i -t [ {イメージ名} [ : {タグ名} ] ] /bin/bash

それでは、実際にdocker-runを使ってみましょう。

# docker run -i -t centos-test /bin/bash
[root@localhost ~]# docker run -i -t centos-test /bin/bash
    == snip ==
[root@ca1d9f6746ab /]#

プロンプトが表示されれたことで、コンテナイメージが起動した事になります。
では起動したコンテナイメージがCentOSであるかを確認する為に、確認の一例として、/etc/redhat-releaseの内容を確認してみましょう。

# cat /etc/redhat-release 
CentOS Linux release 7.1.1503 (Core)

“CentOS Linux release 7.1.1503” と表示されていることから、CentOS 7.1 が起動している事が確認できます。

バージョン指定のコンテナイメージを作成する場合

タグ名に、バージョンとすることで任意のバージョンのコンテナイメージを作成することができます。
以下は、CentOS 6.6 のコンテナイメージを作成する場合の、Dockerfile になります。

# cat Dockerfile 
From centos:6.6
MAINTAINER test<test@test.com>

『Dockerfile』更新後に、『docker-buildコマンド』にてコンテナイメージを作成します。
タグ名に、バージョン番号を入れる事で作成したコンテナイメージの区別ができます。今回は、”6.6″ とバージョンを入れて作成します。

# docker build -t centos-test:6.6 .
Sending build context to Docker daemon 12.29 kB
Sending build context to Docker daemon 
Step 0 : FROM centos:6.6
   == snip ==
Step 1 : MAINTAINER test<test@test.com>
 ---> Running in f580b080006f
 ---> 92592636623e
Removing intermediate container f580b080006f
Successfully built 92592636623e

『docker-imagesコマンド』を使って、ローカルに作成されたコンテナイメージの結果を見てみます。
《centos-test:6.6》が作成されている事が解ります。

# docker images
REPOSITORY          TAG                 IMAGE ID            CREATED              VIRTUAL SIZE
centos-test         6.6                 92592636623e        About a minute ago   202.6 MB
docker.io/centos    6.6                 8b44529354f3        3 months ago         202.6 MB

docker-runコマンドを使って、実際、CentOS 6.6 のイメージが作成出来ているか確認してみましょう。
今回も、redhat-releaseの中身でバージョンの確認をします。

# docker run -i -t centos-test:6.6 /bin/bash
[root@01cd50d320f7 /]# cat /etc/redhat-release 
CentOS release 6.6 (Final)

redhat-release の中が、CentOS release 6.6 となっている事から、CentOS 6.6のコンテナイメージが作成されたと判断できます。

このようにコンテナイメージは簡単に作成することが出来ますので、皆さんも試してみては如何でしょうか?

systemd-journaldを活用しよう

Red Hat Enterprise Linux 7 ではsystemd-journald(以下journald)が導入されています。journaldは従来からあるsyslogと比較すると、細かな時間を表現できたり、ログの中に従来は失われていた優先度などの情報を保持できる、インデックスによる高速な検索、ログのローテートをjournald自身で行うなどの様々な特長を持っています。

レッドハットの森若です。今回はRHEL7でロギングの仕組みとして導入されたsystemd-journaldを紹介します。journaldは従来のsyslogとは大きく異なっており様々な特長を持っています。デフォルトでは各種のログをrsyslogへ配送するための中継ぎとして構成されていますが、永続化して利用することで大変強力なツールとして活用できます。

journaldでのログはどこに保存されるのか?

デフォルトでは/run/log/journal/以下に保存されています。/run以下はtmpfsで、再起動などをすると消えてしまいます。

mkdir /var/log/journal すると/run以下ではなく/var以下に保存します。journaldを活用したいときは迷わず mkdir /var/log/journal しましょう。永続化することによりrsyslogと二重にログを保存することになりますが、ディスク容量を食う以外には特に悪いことは起きません。journaldで一本化できると確信ができたらrsyslogの利用をやめてしまってもかまいません。

実はこのディレクトリ構成はjournaldの特長である、起動直後からのログを統一した形で取り扱えるという性質に関連しています。

initramfs内で起動直後にjournaldを起動します。この時点ではroot fsをmountしていないので、まずはtmpfsで作成された/run 上にログ蓄積をはじめます。この状態のまま継続して動作することもできますが、初期化が順調に進んでroot fsをmountしたあとに、/var以下に/run以下のログを移動させる処理をおこなってログを永続化します。

systemd-journaldでのログ拡張

systemd-journaldではログを幅広く拡張しています。ログに含まれている情報の例を見てみましょう。

  • (アプリケーションが対応していれば)メッセージの文面によらない一意なIDやソースコード上の位置を付加できるためトラブルシュート時に活用しやすい

  • 優先度が保持されるのでログ蓄積後に任意の優先度で検索できる

  • ログを送信したプロセスについての各種情報を保存しているのでIdentifierを正しく設定しないプログラムや偽装するプログラムへの対応にもなる

  • タイムスタンプがマイクロ秒単位となっており、クラスタ環境などで複数マシンにまたがっていてもログの前後関係が把握しやすい

下の図はログ1行分の出力例です。ピンク色の部分が従来のsyslogで保存されていた情報ですので、たくさんの情報が含まれていることがわかります。

ログの表示とフィルタによる検索

journaldのログはバイナリフォーマットになっているのでjournalctlコマンドにより表示をおこないます。journalctlコマンドをただ叩くと一番古いものからページャで表示されます。

単純に保存したログを読むだけでもよいのですが、journaldはそれぞれのフィールドを利用してフィルタを指定し、高速に検索できます。

  • 実行ファイルでのフィルタ

journalctl /usr/bin/pcscd のように実行ファイルのパスをオプションとして渡すことで、実行ファイルによるフィルタをおこないます。

  • 優先度によるフィルタ

journalct -p 4 のように数字0(emerg)から7(debug)までの間で優先度を指定します。たとえば4であればwarning以上の全ての優先度のログを表示します。

  • systemd unit でのフィルタ

systemdのunitでの絞り込みができます。systemdは関連プロセスを追跡しているため、子プロセスの出力も確認できます。たとえば journalctl -u NetworkManager  とすることでNetworkManagerが呼びだす dhclientやModemManagerによるログも確認することができます。

  • 複数条件によるAND検索

journalctl -p 4 /usr/bin/su のように複数の条件を指定することで「Warning以上の優先度で/usr/bin/suから出力されたもの」のようにAND検索による絞り込みがおこなえます。

その他にも起動毎のBOOT IDを保持しているので「journalctl -b -1」として前回の起動時からのログを見たり「journalctl -k」としてカーネルから出力されたログのみを確認することができます。

ログ表示フォーマットの変更

journalctlのデフォルトでは読みだした内容を馴染み深いsyslog風にフォーマットしてくれます。しかしjournaldが保持している情報をどう整形するかは -o オプションで選択できます。

  • journalctl -o short-precise  時刻のみをマイクロ秒単位の表記にし、あとはsyslog風のまま

Jul 16 16:04:11.535406 rhel71.example.com systemd-journal[104]: Runtime journal is using 6.2M (max 49.6M, leaving 74.4M of free 490.2M, current limit 49.6M).
  • journalctl -o json 全てのフィールドを含んだJSON形式での出力

{ "__CURSOR" : "s=ef196eeafe92413cba33aab060cb9029;i=1;b=58f89813972d401ba3591da7067616a3;m=ad1eb;t=51af8adac9c2e;x=cce32c6f2c25f849", "__REALTIME_TIMESTAMP" : "1437030251535406", "__MONOTONIC_TIMESTAMP" : "709099", "_BOOT_ID" : "58f89813972d401ba3591da7067616a3", "PRIORITY" : "6", "_TRANSPORT" : "driver", "MESSAGE" : "Runtime journal is using 6.2M (max 49.6M, leaving 74.4M of free 490.2M, current limit 49.6M).", "MESSAGE_ID" : "ec387f577b844b8fa948f33cad9a75e6", "_PID" : "104", "_UID" : "0", "_GID" : "0", "_COMM" : "systemd-journal", "_EXE" : "/usr/lib/systemd/systemd-journald", "_CMDLINE" : "/usr/lib/systemd/systemd-journald", "_CAP_EFFECTIVE" : "4402800cf", "_SYSTEMD_CGROUP" : "/system.slice/systemd-journald.service", "_SYSTEMD_UNIT" : "systemd-journald.service", "_SYSTEMD_SLICE" : "system.slice", "_SELINUX_CONTEXT" : "kernel", "_MACHINE_ID" : "1e5c5682191d4edcbdb0ff3725e3fdc1", "_HOSTNAME" : "rhel71.example.com" }
  • journalctl -o export  export/import用のテキスト形式

__CURSOR=s=ef196eeafe92413cba33aab060cb9029;i=1;b=58f89813972d401ba3591da7067616a3;m=ad1eb;t=51af8adac9c2e;x=cce32c6f2c25f849
__REALTIME_TIMESTAMP=1437030251535406
__MONOTONIC_TIMESTAMP=709099
_BOOT_ID=58f89813972d401ba3591da7067616a3
PRIORITY=6
_TRANSPORT=driver
MESSAGE=Runtime journal is using 6.2M (max 49.6M, leaving 74.4M of free 490.2M, current limit 49.6M).
MESSAGE_ID=ec387f577b844b8fa948f33cad9a75e6
_PID=104
_UID=0
_GID=0
_COMM=systemd-journal
_EXE=/usr/lib/systemd/systemd-journald
_CMDLINE=/usr/lib/systemd/systemd-journald
_CAP_EFFECTIVE=4402800cf
_SYSTEMD_CGROUP=/system.slice/systemd-journald.service
_SYSTEMD_UNIT=systemd-journald.service
_SYSTEMD_SLICE=system.slice
_SELINUX_CONTEXT=kernel
_MACHINE_ID=1e5c5682191d4edcbdb0ff3725e3fdc1
_HOSTNAME=rhel71.example.com

journaldへのログ送付

journaldへログ出力するにはどうすればいいのでしょうか? 拡張機能を利用しないのであれば、従来のsyslogとおなじように利用できます。

たとえばloggerコマンドを以下のように実行すると

# logger “foobar”

このようなログが保存されます。

__CURSOR=s=ef196eeafe92413cba33aab060cb9029;i=b32;b=58f89813972d401ba3591da7067616a3;m=222d7fb47;t=51afad079c589;x=b44e2b3141f0b6eb
__REALTIME_TIMESTAMP=1437039425340809
__MONOTONIC_TIMESTAMP=9174514503
_BOOT_ID=58f89813972d401ba3591da7067616a3
_UID=0
_GID=0
_MACHINE_ID=1e5c5682191d4edcbdb0ff3725e3fdc1
_HOSTNAME=rhel71.example.com
PRIORITY=5
_TRANSPORT=syslog
SYSLOG_FACILITY=1
SYSLOG_IDENTIFIER=root
MESSAGE=foobar
_PID=18822
_SELINUX_CONTEXT=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
_SOURCE_REALTIME_TIMESTAMP=1437039425340049

アプリケーション用には、標準でCとPython用のライブラリが用意されています。systemd作者のLennertのblogに開発者むけの利用例が記載されています。

関連資料

systemdはmanページが非常に充実しています。

    man systemd-journald.service

    man systemd.journal-fields

    systemd作者のblogにも解説があり参考になります http://0pointer.de/blog/projects/journalctl.html

早くからsystemdを採用していたArch Linuxのwikiには利用に関するhowtoの知識が蓄積されています。

    https://wiki.archlinuxjp.org/index.php/Systemd

 

小ネタ

ページャで行を折り返したい

journalctlで表示をするときに、デフォルトでは行を折り返さずに長い行は横スクロールで読むように設定されています。lessのデフォルトと異なっているのでおどろく方もいるかと思います。

環境変数 SYSTEMD_LESS にページャへのオプションを指定することで折り返しの表示にすることができます。lessの行折り返しをしないオプションは-Sですので、デフォルトの”FRXSMK”からSをのぞいて以下のようにオプションを指定します。

export SYSTEMD_LESS=FRXMK

もろもろの事情で環境変数の設定がむずかしい場合、journalctl -b | less のようにパイプで接続することでオプションなしのlessが利用できます。

tailf /var/log/messages のような監視がしたい

tailfに近い動作をする「journalctl -f」として出力をリアルタイムで継続的に監視できます。この時もフィルタを利用できるので、tailとgrepを利用するよりも便利なケースも多いはず。

シェルでいろいろ属性がついたログ出力をしたい

Fedora 22に含まれているutil-linux ではloggerコマンドに–journald オプションが追加されており、journaldが処理できる各種の属性を付加したログ出力が可能になっています。RHEL7.1で確認したところまだ対応していないので、はやくRHELのutil-linuxも対応するといいですね。

Red Hatテクニカルサポートのつかいかた

Red Hatの製品には問いあわせ回数無制限(!!)のサポートが含まれています。しかし実際には「RHELは利用しているけどサポートにといあわせたことはないよ」という方も多くいるかと思います。今回はレッドハットのサポート利用方法についてご紹介していきます。

レッドハットの森若です。今回はレッドハットの製品サポートについてご紹介します。

テクニカルサポートへの問い合わせ窓口

まず、レッドハットのテクニカルサポートの問いあわせ窓口はどこでしょうか?

レッドハットでは、電話とWebで問い合わせ窓口を用意しています。

電話: 0120-266-668

英語での電話: 0120-655-103

Web: https://access.redhat.com/support/cases/

カスタマーポータル(https://access.redhat.com/ 以下スクリーンショット)の「サポートケースを管理」からサポートケースの一覧を確認したり、「サポートケースを作成」から新規に問い合わせをおこなうことができます。カスタマーポータルのアカウントでログインの上おといあわせください。

 

もしも「質問したいけどカスタマーポータルのアカウントやパスワードがわからない!」という場合には、カスタマーサービスでご対応いたします。 0120-266-668 (オプション 2) までお電話いただくか、customerservice-jp@redhat.com までメールでお問いあわせください。

 

ケースを登録する

「サポートケースを作成」リンクを押すと新規にサポートケースを作成する画面がでてきます。ここに、製品名やバージョン、質問内容を記述することで問いあわせをおこないます。

サポートレベルは24×365のプレミアムか、9時〜17時平日のスタンダードを選択します。該当する製品のサポートレベルをご記載ください。

 

 

重大度とは?

サポートケースを作成するとき「重大度」を設定します。これはたくさんのお客様から同時にお問いあわせをうける中で、どのケースを優先するべきかを決めるために利用されます。

基本的に本番環境での利用で、お客様の業務にインパクトがあり、回避策がないものが高い重大度となります。逆に開発中の問題や、回避策を用いてなんとか業務を継続できるような場合には重大度が低くなります。通常は4で、特別に深刻な場合に重大度をあげて利用します。

  • 重大度1 (緊急) プロダクション用途において、業務を停止せざるを得ない状況で、回避策がない。

  • 重大度2 (高) プロダクション用途において、業務の一部に深刻な影響を与える状況で、回避策がない。

  • 重大度3 (中) プロダクション用途におい て、お客様のビジネスに中から低程度の影響があるが、回避策があり、業務は続けられる場合。 開発用途において、プロジェクトを続行できない、またはプロダクションに移ることのできない状態。

  • 重大度4 (低)  一般的な使用に関する質問、文書エラーの報告、将来の製品改善または修正の推奨。

たとえば「明日ローンチするサイトのテストをしていたらシステムが応答しなくなった!」というような場合、もちろんこの問題はお客様にとって重大な問題なのですが、ここでは重大度は3になります。

重大度はサポート対応のSLAに直結します。24時間対応の対象となるのは重大度1および2 のケースです。重大度1, 2のケースを営業時間外に登録された場合は、初動を早くするためお電話にてご一報ください。

重大度の正式な定義はこちらをご確認ください。 https://access.redhat.com/ja/support/policy/severity

 

サポートにどんな問いあわせができるの?

基本的には製品の使いかたや、発生した問題とその回避策、製品の修正についてのお問いあわせに対応いたします。その他にもドキュメントの問題の指摘や、品質保証チームへのテストケースのご提案もうけつけております。

一方対応できないものとしては、コード開発、システムの設計、セキュリティポリシーを策定すること、既知の修正内容や製品に含まれるプログラムの解説などは範囲に含まれません。

たとえばRHELにはOpenJDKのサポートが含まれています。これを例にしてサポート可否をみてみましょう。

「OpenJDKでヒープメモリ4GBに設定したいんだけどどうしたらいいの?」「今までのバージョンでは動作していたプログラムをOpenJDKの新しいパッケージで起動したらJDKごとクラッシュするようになったのでOpenJDKの問題じゃない? 」というようなお問いあわせはサポート対象になります。

しかし「OpenJDK上で動作するプログラムを作っているけどNullPointerExceptionがでてこまるので助けて」というような場合はコード開発にあたりサポート対象にはなりません。

正式な定義はこちらをご確認ください。https://access.redhat.com/ja/support/offerings/production/soc

サポートされるパッケージとサポートされないパッケージ

「Red Hat Enterprise Linux」を購入すると入手・利用できるパッケージは多数ありますが、この全てがサポート対象になるわけではありません。サポート範囲の定義のページに記載がありますが「コア機能」と呼ばれるものがサポートの対象になります。たとえばfirefoxはコア機能ですが、firefoxを動作させるために必要となる多くのライブラリはコア機能ではありません。

あるパッケージがコア機能に含まれるかはRHELドキュメント中の「Package Manifest」というドキュメントに記載されています。どのパッケージがコア機能になるかはサーバ版やデスクトップ版といった版によっても変わります。たとえばLibreOfficeはサーバ版ではコア機能ではありませんが、ワークステーションではコア機能としてサポート対象になります。

また「Optional」および「Supplementary」とされているリポジトリ(またはチャネル)経由で配られている追加のソフトウェア群があります。これらはデフォルトでは利用できず、リポジトリを有効にすることで利用できるようになりますがサポート対象とはなりません。

問い合わせ対応をスムーズにするsosreport

テクニカルサポートへの問いあわせをおこなう場合、多くのお客様がログや画面出力から自分が気になった部分を送ってくださるのですが、それだけでは何とも言えないケースが多くあります。一口にRHELといっても様々なバージョンや設定・構成があり、同じような問題にも複数の原因が考えられることが理由のひとつです。多くのケースでは問題を絞り込むためにお客様の環境を把握することが必要で、お客様へ各種の情報収集をお願いすることになります。

トラブルシュート時に典型的に必要な情報はわかっていますので、レッドハットではこの情報収集を sosreport とよばれるソフトウェアで自動化しています。sosパッケージをRHELにインストールし、root権限でsosreportコマンドを実行することで、各種の設定やログを収集したアーカイブを作成してくれます。このアーカイブをあらかじめサポートケースに添付していただくことで、スムーズな対応が可能になります。

sosreport実行例:
[root@rhel7 ~]# sosreport
sosreport (version 3.2)

This command will collect diagnostic and configuration information from
this Red Hat Enterprise Linux system and installed applications.

An archive containing the collected information will be generated in
/var/tmp and may be provided to a Red Hat support representative.

Any information provided to Red Hat will be treated in accordance with
the published support policies at:

  https://access.redhat.com/support/

The generated archive may contain data considered sensitive and its
content should be reviewed by the originating organization before being
passed to any third party.

No changes will be made to system configuration.

Press ENTER to continue, or CTRL-C to quit.

Please enter your first initial and last name [rhel7.example.com]:
Please enter the case id that you are generating this report for:

 Setting up archive ...
 Setting up plugins ...
 Running plugins. Please wait ...

  Running 10/86: cluster...       

sosreportについて詳しくは以下のナレッジベースをごらんください。

https://access.redhat.com/ja/solutions/78443

参考情報

レッドハットの製品サポートについての各種ポリシーを以下でご案内しています。

https://access.redhat.com/support/offerings/production/

Red Hat Enterprise Linux のサポートポリシーについてよく利用されるナレッジ

Red Hat Enterprise Linux 7でスナップショットとり放題生活をしてみよう

Red Hat Enterprise Linux 7ではスナップショットを低いコストで実現するLVM thin provisioningによる論理ボリュームがサポートされています。この記事ではLVM thin provisioning環境へのインストールと、基本的なスナップショットの作り方を説明したのち、定期的なスナップショットの取得やファイルの差分取得を簡単にできるsnapperを紹介します。

レッドハットの森若です。

今回はRed Hat Enterprise Linux 7で登場したLVM thin provisioningによるスナップショットのサポートと、このスナップショットを活用するsnapperをご紹介します。

インストール

RHEL7のインストーラではインストール対象としてLVM thin provisioningが選択できるようになっています。ここを選択して、容量を設定することでこの後説明するスナップショット機能が利用できるようになります。

状態を確認

操作する前にlsblkコマンドで現在の状態を確認しましょう。
[root@localhost log]# lsblk
NAME                    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda                       8:0    0   20G  0 disk 
├─sda1                    8:1    0  500M  0 part /boot
└─sda2                    8:2    0 16.4G  0 part 
  ├─rhel-swap           253:0    0    2G  0 lvm  [SWAP]
  ├─rhel-pool00_tmeta   253:1    0   12M  0 lvm  
  │ └─rhel-pool00-tpool 253:3    0   12G  0 lvm  
  │   ├─rhel-root       253:4    0   12G  0 lvm  /
  │   └─rhel-pool00     253:5    0   12G  0 lvm  
  └─rhel-pool00_tdata   253:2    0   12G  0 lvm  
    └─rhel-pool00-tpool 253:3    0   12G  0 lvm  
      ├─rhel-root       253:4    0   12G  0 lvm  /
      └─rhel-pool00     253:5    0   12G  0 lvm  
sr0                      11:0    1  3.6G  0 rom  

[root@localhost log]# lvs
  LV     VG   Attr       LSize  Pool   Origin Data%  Meta%  Move Log Cpy%Sync Convert
  pool00 rhel twi-aotz-- 12.00g               9.38   5.18                            
  root   rhel Vwi-aotz-- 12.00g pool00        9.38                                   
  swap   rhel -wi-ao----  2.00g
lsblkに同じエントリ(rhel-rootとrhel-pool00)が2回でているので不安になるかもしれません。tmetaの方はメタデータ、tdataの方は実際のデータがはいっていてこの2つの組み合わせでrhel-rootとrhel-pool00が実現されています。
この例では12GBのpool00の下に12GBということになっているrootが含まれている状態です。
プールの詳細は、lvdisplayコマンドで確認します:
  [root@localhost log]# lvdisplay /dev/rhel/pool00 
  --- Logical volume ---
  LV Name                pool00
  VG Name                rhel
  LV UUID                vuooGK-VHow-JfAo-cPQb-Egf1-fCk4-qRpLqK
  LV Write Access        read/write
  LV Creation host, time localhost, 2015-05-15 19:15:03 +0900
  LV Pool metadata       pool00_tmeta
  LV Pool data           pool00_tdata
  LV Status              available
  # open                 2
  LV Size                12.00 GiB
  Allocated pool data    9.38%
  Allocated metadata     5.18%
  Current LE             3072
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     8192
  Block device           253:3
これで、lvmにより任意のタイミングでsnapshotをとり放題です。以下のようなコマンドでスナップショットを作成できます。
 # lvcreate --permission r --snapshot --name snapshot rhel/root 

snapperの初期設定

ここまででsnapshot作り放題なのは良いのですが、lvcreateで都度作成するのはスナップショットの名前を指定したり、定型的なオプションを指定する必要があるため煩雑です。そのためRHEL7には、SUSE出身のsnapperが含まれています。とても便利ですのでここからはsnapperをご紹介していきましょう。
まずは管理対象のディレクトリ(通常はマウントポイント)毎にsnapperの設定を作成します。デフォルトだと “root” という名前の設定で、それ以外だと-c “設定名” のようにオプションをつけて実行します。
[root@localhost ~]# snapper create-config -f 'lvm(xfs)' / 
このコマンドにより /etc/snapper/configs/rootに設定本体が作成され、
さらに設定一覧が /etc/sysconfig/snapper にあるのでここに設定名が追加されます。
snapperが持っている設定の一覧を確認します。”root”設定があるのがわかります。
[root@localhost log]# snapper list-configs 
Config | Subvolume
-------+---------- 
root | / 

snapshot作成

ここまで準備をするとスナップショットの作成は簡単。snapper createコマンドを実行するだけです。
 [root@localhost log]# snapper create 
様子を確認します。
[root@localhost log]# snapper list
Type   | # | Pre # | Date                     | User | Cleanup | Description | Userdata
-------+---+-------+--------------------------+------+---------+-------------+---------
single | 0 |       |                          | root |         | current     |         
single | 9 |       | Mon May 18 18:15:10 2015 | root |         |             |         

[root@localhost log]# lvs
  LV             VG   Attr       LSize  Pool   Origin Data%  Meta%  Move Log Cpy%Sync Convert
  pool00         rhel twi-aotz-- 12.00g               10.00  5.73                            
  root           rhel Vwi-aotz-- 12.00g pool00        10.00                                  
  root-snapshot9 rhel Vri---tz-k 12.00g pool00 root                                          
  swap           rhel -wi-ao----  2.00g
この例では、root-snapshot9 という名前のスナップショットが作成されています。snapperでは元の論理ボリュームのあとに”-snapshot<スナップショット番号>”をつけた名前を生成し、自動的に名付けてくれます。さらにスナップショット作成時刻や、オプションで指定することで任意のメモを付与することができます。

スナップショットのマウント

復旧作業を行うような場合には、スナップショットをマウントして、中のファイルやディレクトリを利用できます。
snapper mount サブコマンドにスナップショット番号をオプションとして指定することで、readonlyでmountすることができます。
管理対象ディレクトリ以下の、.snapshotディレクトリに例のようなディレクトリが作成され、mountされます。
以下の例ではスナップショット 10番をマウントし、dfコマンドでマウントされていることを確認しています。
[root@localhost ~]# snapper mount 10 

[root@localhost ~]# df

Filesystem                        1K-blocks    Used Available Use% Mounted on
/dev/mapper/rhel-root              12571648 1226516  11345132  10% /
devtmpfs                            1931348       0   1931348   0% /dev
tmpfs                               1941204       0   1941204   0% /dev/shm
tmpfs                               1941204    8580   1932624   1% /run
tmpfs                               1941204       0   1941204   0% /sys/fs/cgroup
/dev/sda1                            508588  168516    340072  34% /boot
/dev/mapper/rhel-root--snapshot10  12571648 1193528  11378120  10% /.snapshots/10/snapshot 

snapshot間の差分

snapperではsnapshotと現在のファイルシステムの分を取る仕組みがあります。
仕組みは簡単で、一時的なディレクトリにmountしておいてdiffを実行しています。
さらにスナップショットの属性としてpreとpostというタイプが導入されています。スナップショットの仕組み自体は同じなのですが、なんらかの作業前にpreスナップショットを取得、作業後にpostスナップショットを取得してペアにしています。postスナップショットを作成すると、snapperが自動的に対応づけられたpreスナップショットとの差分をバックグラウンドで取得し、作業によるファイル変更情報をまとめます。
preスナップショット作成
[root@localhost ~]# snapper create -t pre 
 [root@localhost ~]# snapper list Type   | #  | Pre # | Date                     | User | Cleanup | Description | Userdata -------+----+-------+--------------------------+------+---------+-------------+--------- single | 0  |       |                          | root |         | current     |          single | 9  |       | Mon May 18 18:15:10 2015 | root |         |             |          pre    | 10 |       | Mon May 18 18:18:32 2015 | root |         |             |
適当にファイルを変更
[root@localhost ~]# rm hoge 
rm: remove regular empty file ‘hoge’? y 
preスナップショット10番に対応するpostスナップショットを作成
[root@localhost ~]# snapper create -t post --pre-number=10

[root@localhost ~]# snapper list
Type   | #  | Pre # | Date                     | User | Cleanup | Description | Userdata
-------+----+-------+--------------------------+------+---------+-------------+---------
single | 0  |       |                          | root |         | current     |         
single | 9  |       | Mon May 18 18:15:10 2015 | root |         |             |         
pre    | 10 |       | Mon May 18 18:18:32 2015 | root |         |             |         
post   | 11 | 10    | Mon May 18 18:19:42 2015 | root |         |             |
差分の確認
[root@localhost ~]# snapper status 10..11
-..... /root/hoge
c..... /var/log/messages
c..... /var/log/snapper.log

差分対象の制限(フィルタ)

さきほどの例をみると、hogeファイルが消えているのと、/var/log以下のログが増えていることが表示されます。
ログの差分をとってもあまり嬉しくないような場合は、/etc/snapper/filters/ に、log.txtという名前で以下のようなファイルを作成します。このfilterディレクトリ内のファイルで指定されたパターンにマッチするファイルは差分チェックの対象になりません。
差分対象の制限
 /var/log/* 
差分の確認ふたたび
 [root@localhost ~]# snapper status 10..11
 -..... /root/hoge 

undochange

差分がとれるので、patchコマンドの要領でundoができます。
ただこのundoをした時に一貫性があるのか、もろもろ大丈夫なのかなどは特に保証されていませんので注意が必要です。この例では削除されたファイル “hoge” がスナップショットからコピーされて復旧します。
 [root@localhost ~]# snapper undochange 10..11
 create:1 modify:0 delete:0 

関連ドキュメント

snapperにはこの他にも定期的にsnapshotをとっておいて、過去数回分を残しておくなどの機能があります。ここでは説明できなかった点も多数ありますので、関連するドキュメントへのリンクを以下に記載します。

Red Hat Enterprise Linuxのセキュリティ対応に OpenSCAPを活用しよう

「システムに既知の脆弱性や問題のある設定がないかチェックをしよう」というとき、あなたならどうしますか? 本稿ではセキュリティ対応の自動化のためRHELに最近導入されたOpenSCAPおよびSCAP Security Guideを紹介します。

セキュリティ対応、どうしてますか?

「システムに既知の脆弱性や問題のある設定がないかチェックをしよう」というとき、あなたならどうしますか? 緊急の対策については、文書をもとに手作業で確認するケースも多いかと思います。しかし組織内での恒常的なセキュリティ対応のためには、自動化が必要になります。

本稿ではセキュリティ対応の自動化のためRHELに導入されたソフトウェアを紹介します。

SCAP(Security Content Automation Protocol)

アメリカ政府ではあらゆるシステムにセキュリティ対応(発見・対策)をおこなう必要があり、これを自動化・定型化するための仕組みが作られてきました。SCAPはNIST(National Institute of Standards and Technology)により開発された、情報セキュリティ対策の自動化と標準化のための規格です。前提となる各種のID策定、セキュリティ上の問題の検出と対策などを記述するフォーマットなどを規定しています。

SCAPの一環として、製品についてのID(CPE)、 脆弱性についてのID(CVE)、設定についてのID(CCE), 脆弱性の深刻さのスコアづけ(CVSS)、自動チェックのための言語(OVAL)、チェックリストのフォーマット(XCCDF)などが標準化されています。脆弱性情報などでCVEやCVSSの名前を見たことがある方も多いのではないかと思います。

OVAL規格では各種のOSやアプリケーションに対応しており、テスト項目を「ファイルや設定、パッケージなどの検査項目」と「どういう状態になっているか」の組み合わせで記載して専用の処理系によって自動的に検査することができるようになっています。

SCAPについて詳しくはIPAのSCAP概説ページをごらんください。関連する規格についても紹介がされています。Red Hat製品についても従来からアップデート情報をOVALフォーマットで提供しています

この記事では、このSCAPに関連した以下の3つのソフトウェアを紹介します。

  • XCCDFまたはOVAL形式のファイルを処理するOpenSCAP

  • XCCDFフォーマットで作成された包括的なチェックリストであるSCAP Security Guide

  • XCCDFフォーマットのチェックリストを必要にあわせてカスタマイズするSCAP Workbench

OpenSCAP

OpenSCAPは、SCAPを実装しているオープンソースのプロジェクトで、OpenSCAP 1.0.8 でSCAP 1.2の認証をNISTから受けています。OpenSCAPはOVALまたはXCCDFで記述されたチェックリストと組織にあわせたカスタマイズにしたがって、実際のシステムを検証してレポートを作成します。一部の項目については自動的な対策も可能です。

OpenSCAPの利用方法のイメージはドキュメントに、DISAが公開しているガイドを利用してチェックを行う例などがあります。OpenSCAPはRed Hat Enterprise Linux の5.7および6.0から同梱されています。

 

OpenSCAPで出力されるレポート例

 

SCAP Security Guide

SCAP Security Guide は、Fedora, Java, Red Hat Enterprise Linux 5, 6, 7, OpenStack, JBoss Enterprise Application Server 5, JBossFuse6 のセキュリティについてついてのガイドと関連する検証メカニズムをXCCDF形式で提供しているプロジェクトです。

 

SCAP Security Guide内には「/var/logを別のパーティションにする」といった多数のチェック項目と説明、関連するIDや規格文書などへのリファレンス、自動でチェックや修正が可能なものについてはその手順が含まれます。これらの項目から組織のポリシーにあわせて選択してカスタマイズしたチェックリストを作ります。OpenSCAPはこのチェックリストを自動でチェックしてレポートを生成します。オプションによっては自動的な修正もおこないます。

 

このプロジェクトは2011年にRHEL6についての高品質なセキュリティガイドを作成するためのNSAとRed Hatの共同作業からはじまり、その後カバーする範囲や参加者を増やしつつ成長しています。RHEL 7.1からSCAP Security Guideが同梱されるようになりましたので「SCAP Security GuideをSCAP WorkbenchでカスタマイズしたチェックリストをOpenSCAPで自動的に確認し、レポートを作成する」プロセスの全体をRed Hatがサポートできるようになりました。

 

SCAP Workbench

SCAP WorkbenchはXCCDF内でのチェック項目を組織にあわせて選択・調整したプロファイルを作り、ローカルまたはリモートの環境をチェックする作業を簡単にするためのGUIツールです。RHEL 7.1からはサポート対象として同梱されています。

 

Red Hat Enterprise Linuxのセキュリティ対応に

 

Red Hat Satelliteからの管理

Red Hat Satelliteから管理対象になっている複数台のRHELに対してOpenSCAPを実行してレポートを蓄積します。監査結果の概要や履歴を確認したり、同一のスキャンを行って前回との差分を確認するなどの機能が提供されます。以下はRed Hat Satellite 5.7でのスキャン結果概要画面の例です。

 

関連資料

 

RHEL 7.0時点のもので現在とは多少見た目がちがいますが紹介ビデオがあります

(レッドハット ソリューションアーキテクト 森若和雄)

Red Hat Directory Server 10.0リリース!

今回は2015年6月16日に出荷されたRed Hat Directory Server 10 をご紹介します。RHDSはNetscape Directory Serverを買収したRed HatがOSS化したLDAPサーバで、高い互換性によりSolarisなどからの移行時に活躍します。またOpenLDAPに無い企業向けの様々な機能も搭載しています。

レッドハットの森若です。今回は2015年6月16日に出荷されたRed Hat Directory Server 10 をご紹介します。

Red Hat Directory Server とは?

Red Hat Directory Serverは汎用のLDAPサーバで、主にアカウントにひもづく情報を格納するために利用されます。住所、氏名、生年月日、性別、電話番号、メールアドレス、認証用のパスワード、顔写真、役職などの人に直接ひもづく情報に加えて、権限管理をするためのグループ情報、ロール情報、サーバ情報や各種の設定といった多様なデータを保持します。

LDAP v3の各種規格に準拠した通常のLDAPサーバとしての基本機能に加えて企業での大規模な運用を便利にする種々の追加機能を提供しています。Red Hat Enterprise Linux 7.1以降で動作し、5年間のサポート期間が設定されています。upstream projectは389 Directory Serverです。

Red Hat Directory Serverの生い立ち

実はRed Hat Directory Serverは世界初の商用LDAP製品であるNetscape Directory Serverの直系の子孫でもあります。ミシガン大学で作成された世界初のLDAPサーバslapdから派生した商用LDAP製品として、1996年からNetscape Directory Serverの開発がはじまりました。OpenLDAPも同じslapdから派生したものです。

最初はNetscape社が一社で開発していましたが、1998年からはSun MIcrosystems社とアライアンスを組んでiPlanet Directory Serverという名前で開発・販売していました。2002年にアライアンスが終了し、その時点での製品についてAOL社(この時点でNetscape社はAOLに買収されていました)とSun Microsystems社はどちらも権利を得てSunはiPlanet Directory Server, AOLは Netscape Directory Serverとして開発を継続します。

2004年にRed HatはAOLからDirectory ServerおよびCertificate Systemの事業を開発メンバーとともに買収し、ここにRed Hat Directory Serverが誕生しました。2005年にオープンソース化し、コミュニティプロジェクトとしてFedora Directory Serverが立ちあがり、のちに改名して389 Directory Serverとなっています。

現在では389 Directory Serverプロジェクトで主な開発作業を行い、これにテスト, ドキュメント, サポートなどを付加して製品化したものがRed Hat Directory Serverとなっています。

ライフサイクルと動作環境

最近のバージョンでは、RHDS 8はRHEL5上で、RHDS 9はRHEL6上、RHDS 10はRHEL7上というように、動作環境となるRHELのバージョンをきりかえるタイミングでメジャーバージョンが更新されています。またRHDS8まではSolarisなど他社OS上でも動作する版が販売されていました。

https://access.redhat.com/support/policy/updates/directory/

Red Hat Directory Serverのサポート期間はGAから5年間です。現在サポート対象になっているバージョンと期限は以下の通りです。

  • RHDS8 (RHEL5)    2015年8月
  • RHDS9 (RHEL6)    2017年6月
  • RHDS10 (RHEL7)    2020年6月

OpenLDAPと比較したときのRed Hat Directory Server 10 の特徴は?

同じミシガン大学のLDAPサーバ由来のOpenLDAPと比較すると、Red Hat Directory Server 10には以下のような特徴があります。

  • JavaによるGUIでの管理コンソール
  • 最大20ノードまでサポートされるマルチマスターレプリケーション
  • Windows 2008 R2, 2012, 2012 R2 のActive Directoryとの同期機能
  • 任意の属性を暗号化して保存
  • マクロをもちいたACLの定義などの強力なアクセス制御機能
  • バックアップなどの管理操作をTaskとしてLDAPサーバに統合
  • プラグイン開発用インタフェースの提供
  • Class of ServiceとRoleのサポート
  • Virtual Viewにより属性によるダイナミックなツリーを提供
  • SunDSやOracle DSEEとの高い互換性

 

残念ながら英語のみで日本語訳はないものの、非常に充実したドキュメントが存在することもRHDSのポイントです。RHDS10のドキュメントには通常の利用方法の他に、LDAPサーバの構築時に必要な考慮点や、既存のRHDS 7,8,9からの移行手順なども記載されています。

RHDS8まではクライアント用ライブラリやツールがOpenLDAPと異なっていましたが、RHDS9からはOpenLDAPのクライアントがそのまま利用できるようになっています。

Solaris, HP-UX, AIXから移行するような場合は?

SunDSやOracle DSEEからLinuxへ移行するような場合、またSolarisやHP-UX、AIX向けに過去に出荷されていたRHDSからLinux上のLDAPサーバへの移行の場合にも、RHEL上のRHDSは有力な移行先の候補になります。

OpenLDAPではサポートされていないNetscape時代に拡張されたロールや時間ベースアクセス管理などの権限管理機能、管理コンソールなど多くの点で共通点があるRed Hat Directory Serverは有力な移行先の候補になるでしょう。

費用は?

RHDSはCPUのコア数やアカウント数ではなく、サーバ台数単位での価格になっています。

ソフトウェアとしては全く同じですが、クライアントから更新をうけつける通常のサーバ(195万円/台)と、クライアントからの更新をうけつけない読み込みのみのレプリカ(39万円/台)で価格が異なります。

動作環境としてRHEL Serverが別途必要で、サポートレベルはRHEL Serverのサポートレベルに準じます。

関連資料

OpenStack Days Tokyo 2015 現地レポート

2015年2月3〜4日の2日間にわたり、オープンソースのクラウド基盤構築ソフトウエア「OpenStack」をテーマにしたイベント「OpenStack Days Tokyo 2015」が開催された。本稿では、特に、レッドハット社ならびにサイオステクノロジー社の取り組みを中心にして、OpenStack Days Tokyo 2015のレポートをお届けしたい。


なんといっても、注目点は、当日の参加者の数と熱気だろう。セミナーでは多数の立ち見の参加者がでるほどの大きな盛り上がりを見せ、また、各社のソリューションを展示したコーナーでは熱心な参加者がベンダーと話をしていた。OpenStackに対する市場での期待の高さを反映するものとなった。

初日の基調講演に登場したのは、OpenStackプロジェクト共同創始者の1人でOpenStack FoundationのCOO(最高執行責任者)のMark Collier氏が登壇し、『OpenStack Scope : How we’re making the core smaller while embracing the freedom to innovate around it』と題して、OpenStackの現状や課題、今後の注力分野などを語った。この基調講演は、多くのメディアで報道されているので、ぜひ参考にして欲しい( 参考: http://enterprisezine.jp/iti/detail/6561 )

盛り上がりを見せた初日最後の講演を飾ったのが、レッドハット SDN担当テクニカル・ディレクター 兼 OpenDaylightプロジェクト ボードメンバーであるChris Wright氏である。

Wright氏は、『OpenStackとNFVの関係、OpenDaylightプロジェクト最新情報』と題して、オープンソースのSDNコントローラーのプロジェクト「OpenDaylight」の概要および高速化技術を中心としたNFVのプロジェクト「OPNFV」や、OpenDaylightプロジェクトから見た、NFV/SDNとOpenStackの最新情報を紹介した(講演資料PDFは、こちら からダウンロード可能)

アップストリームファースト

Wright氏がまず、強調したのがコミュニティとレッドハットとの関わりについてだ。レッドハットでは、「アップストリームファースト」というモデルを提唱している。アップストリームとは、Linuxなどのオープンソースのコミュニティが開発・メンテナンスをしているソースコードのことを指す。レッドハットのようなLinuxディストリビューションベンダーは、アップストリームで開発されたLinuxカーネルに加えて、多くのオープンソースコミュニティが開発したコンポーネントを組み合わせたパッケージを作成する。

レッドハットでは、アップストリームで開発されたソースコードを組み合わせて、まず、コミュニティプラットフォームを提供するコミュニティを支援する。その後、サポートやソリューションが必要となる企業や団体などに有償で販売するパッケージを提供するというモデルとなっているのだ。OpenStackやJBossなどにおいても同じ考え方で体制が作られることになる。

 

NFVとレッドハットの取り組み

続いて、詳しく紹介されたのは、NFV(Network Functions Virtualization)についてだ。NFVというキーワードは、読者も最近に耳にすることも多くなっただろう。サーバーの仮想化、クライアントの仮想化、ストレージの仮想化と並び、ネットワークにおいても、「ネットワークの仮想化」に注目が集まる。その中で、SDNと並んで、今、最もホットな話題の1つと言えばNFVといえるかもしれない。

現在、ネットワーク機能の多くは、専用ハードウェア上で一体化したネットワーク専用機として提供されている。それでは、購入・インテグレーション・デプロイ・運用には高価になりがちだ。NFVは、仮想化技術を使ってネットワーク機能をx86サーバーのような汎用プラットフォーム上で実現する。このことにより、コストが削減できるだけでなく、「新しいサービスをタイムリーにリリースできるようになる」(Wright氏) という。

NVFが関係するコミュニティは、ETSI(欧 州電気通信標準化機構:European Telecommunications Standards Institute)のNFV ISG(Industry Specification Group)、OPNFV、OpenStack およびインフラ機能を提供するlibvirt, qemu/KVM, Ceph, Open Daylight, Open vSwitchであるという。

これらのコミュニティの中から、Wright氏は、2014年9月に発足したOpen Platform for NFV(OPNFV)について紹介する。OPNVFとは、レッドハット、AT&T、Cisco、HP、NTTドコモなどの通信・ネットワーク関連企業が、Linux Foundationと協力して、新たなオープンソースプロジェクトである。OPNVFは、オープンなNFVリファレンスプラットフォーム構築のために、一貫性のある標準の実装を進める。この活動にも共通するフィロソフィーは、アップストリームファーストだ。そして、さまざまなコミュニティと協調して、プロジェクトを推進するというスタンスも変わらない。レッドハットしては、この成果をRed Hat Enterprise Linux OpenStack Platformに取り入れていくとする。

OpenDaylightプロジェクト,Open vSwitchとDPDK

そして、Wright氏がボードメンバーをつとめるOpenDaylight プロジェクトの最新情報を紹介した。

OpenDaylightは、Linux Foundationが2013年4月に開始したオープンソースのSoftware Defined Network(SDN)プロジェクトである。OpenDaylightでは、広範囲なベンダーのスイッチやルーター、ファイアウオールなどのデバイスをコントロールできるSDNコントローラーを提供する。2014年2月にOpenDaylightの最初のバージョンであるHydrogenを公開し、2番目のバージョンであるHeliumを2014年9月にリリースした。レッドハットでは、OpenDaylightプロジェクトのプラチナメンバーとして、OpenStack用のネットワーク仮想化などにフォーカスして活動しているという。

さらに、OpenFlowをサポートする仮想環境でのオープンソースの仮想スイッチOpen vSwitch、Linuxカーネルの代わりに、ネットワークパケットを処理するアプリケーションを独自に作成することが可能とするDPDK (Data Plane Development Kit) を紹介し、インテルの検証結果やOpenStack, OpenDaylightコントローラー、Open vSwitch, DPDKを組み合わせたアーキテクチャーを示した。

最後に、レッドハットは、このような多くのプロジェクト、コミュニティが活動するネットワーク領域において、スポンサーとして、また、開発をリードするエンジニアが活躍することにより、NFVに対する取り組みを強化していくと、

Wright氏は、NFVへの取り組み全体をまとめて講演を終了した。

このようにネットワーク仮想化周辺は、多くのコミュニティやプロジェクトが同時並行で早く動いていく。このような意味で、本講演は、今、話題のキーワードであるSDN, NFV, OpenDaylightなどを一覧で理解できたよい機会ではなかっただろうか。これからも、この分野の動きは急速だと思われるので、ぜひ引き続きフォローして欲しい。

展示会フロアーに目を移すと、レッドハットは、OpenStackディストリビューション「Red Hat Enterprise Linux OpenStack Platform」をはじめ、OpenStack、VMware、Amazon Web Servicesを統合管理できるクラウド管理プラットフォーム「CloudForms」、注目度が上昇しているPaaS領域での「OpenShift」など、OSSベースのクラウド製品を紹介していた。

 

サイオステクノロジーのOpenStackへの取り組み

本サイトを運営するサイオステクノロジー株式会社のセッションにも、他のセッションと同様に多数の参加者が集まり、立ち見がでる盛況さであった。セッションは、タイトル『OSSならサイオス ~OpenStackを考察してみる』と題して、OSS テクノロジーセンター長 黒坂 肇氏とレッドハット製品担当 杉崎道夫氏が、講演を行った。

まず、黒坂氏が、OpenStackだけでなく、オープンソース全体の動向を含めての紹介、また、課題を紹介した。そして、最後に、杉崎氏が、サイオステクノロジー社ブースでのデモンストレーション概要を説明した。

そのブースでは、ネットワールド社から協力を得て、ネットワールド社の環境に構築したRed Hat Enterprise Linux OpenStack Platformにネットワーク経由で接続し、デモンストレーションを実施していた。ネットワールド社によれば、NetApp社のストレージ機能を活用することで、IOボトルネックを解消し、効率的な運用ができるという。

具体的には、clustered Data ONTAP と協調し、NetApp Unified Driver の拡張したCopy Offloadなどを活用し、紹介していた。多数のサービスが稼働するOpenStack環境では、さまざまなサーバーが稼働している。そして、新しいサーバーを稼働させることも必須だ。

そ のとき、サーバーのリソースをすべて利用して、データのロード、ストアが実施することは、少なからずの不可をサーバーにかけることになる。これを、 Copy Offload機能などを利用することで、ストレージが得意なIO処理をサーバーのリソースを使用せずに、ストレージに任すことで負荷をオフロードするこ とができる。

つまり、サーバーリソースの消費を削減することができるため、OpenStack 環境で、より多くのインスタンスを稼働させることができ、また、余計な負荷をかけずに済むという。

効率的な運用管理には、餅は餅屋に任せる=ストレージについては、ストレージに任せるといったことも重要になるということだ。

実際のデモンストレーションの構成と内容は、ネットワールド社作成の以下の資料と動画を参照して欲しい。

  • OpenStack Cinderを使ったボリューム管理 NetApp Unified Driver スナップショット連携編

 

  • OpenStack Cinderを使ったボリューム管理 LVM連携編

主催者によれば、2日間の参加者は2000人を越えたという。この盛り上がりは、おそらく今年秋に開催されるOpenStack Foundation主催のOpenStack Summit にも引き継がれていくだろう。それまでに、どのようなベンダーや企業が新たな取り組みを発表するのか、期待したい。

PS. 写真はサイオステクノロジー社イベントでおなじみになった「おーぷんソイそーす」