John Levon著
2015年1月公開
Oracle Solarisカーネル・ゾーンは、最新タイプのOracle Solarisゾーンであり、Oracle Solaris 11.2より提供されています。カーネル・ゾーンは、Oracle Solarisゾーンの柔軟性、スケーラビリティ、効率性をすべて備え、さらに独立したカーネルを含むゾーンを作成できる機能が付加されています。この機能は、異なる所有者に属する複数のゾーン環境のアップデートを調整する場合に特に便利です。
|
カーネル・ゾーンを利用すれば、それぞれの所有者にとって都合のいいときに、個々のカーネル・ゾーンのレベルでアップデートを実行できます。さらに、バージョンに関する詳細な要件のある複数のアプリケーションを同じシステム上で並行実行して、Oracle Solarisゾーンによる高い統合率のメリットを受けることができます。
この記事では、カーネル・ゾーンのデプロイにおける一般的なベスト・プラクティスについて説明します。それぞれの環境における最良の構成は、カーネル・ゾーンの利用方法によって異なるため、この記事は検討の出発点として利用してください。たとえば、再現性のあるパフォーマンスを最適化するために、特定のリソースをカーネル・ゾーン専用に割り当てたい場合があるでしょう。そのようなケースで、以降で説明しているデフォルトのvirtual-cpu
リソースを利用してシステム上の他のワークロードとCPUリソースを共有させるのは望ましくありません。
一般に、ホストはゾーンを実行するために用意します。大域ゾーン内で直接アプリケーションを実行するためではありません。ただし、単一のホストで異なるタイプのゾーンをホストするのはかまいません。
カーネル・ゾーンの利用時には、アプリケーションのメモリ使用率に関するヒントをシステムに提示する必要があります。この情報は、ZFS適応型置換キャッシュ(ARC)の拡大を制限し、アプリケーション(この場合はカーネル・ゾーンそのもの)で利用可能なメモリ量を増やすために使用されます。
このヒントを提示するには、user_reserve_hint_pct
パラメータの値を設定します。この操作のためのスクリプトが提供されています。たとえば、次のコマンドは、この値に80を設定します。
root@global:~# ./set_user_reserve.sh -f 80 Adjusting user_reserve_hint_pct from 0 to 80 Adjustment of user_reserve_hint_pct to 80 successful.
このスクリプトやその他の詳細情報については、My Oracle Support Webサイトにアクセスし、Doc ID 1663862.1を参照してください。
この値の設定によって、ホストで大量のキャッシュが割り当てられなくなるため、ホスト上のZFSパフォーマンスに影響が出る可能性があります。ネイティブ・ゾーンを利用したい場合や、カーネル・ゾーンをZFSボリューム・ストレージとともに利用したい場合(どちらもホストのZFSドライバを使用する)、この値を調整する必要があるでしょう。
デフォルトの2GBのメモリ・サイズ(capped-memory:physical
)が最小メモリ構成です。ほぼ確実に、このサイズを増やす必要があります。たとえば、大きめのワークロードに対しては16GB程度が適しています。
デフォルトでは、カーネル・ゾーンには1つの(仮想)CPU、つまり1つの実行スレッドが割り当てられます。おそらく、この数値を変更し、カーネル・ゾーンに割り当てるCPUリソースを増やすといいでしょう。
CPUアーキテクチャの違いにより、x86プラットフォームとSPARCプラットフォームは大幅に異なる点に注意してください。実行パフォーマンスの観点では、1基のSPARC "CPU"は、1基のx86 "CPU"に相当しません。以下の説明のとおり、通常はCPUコアという点から検討するべきです。
ネイティブ・ゾーンと同様に、基本的な選択肢は2つあり、ホストCPUをカーネル・ゾーン専用に割り当てるか、ホストCPUを他のゾーンと共有させます。
最適なパフォーマンスを目指す場合は、dedicated-cpu
リソースを用いて、ホストCPUをカーネル・ゾーン専用に割り当てます。そうすれば、それらのCPU上では、カーネル・ゾーンのみが稼働することになります。
ゾーンの各CPUスレッドは、CPUセット内のいずれかの物理CPU上で実行するようにスケジュール設定でき、ゲストの実行時に物理CPU間で移動できます。ただし、ゲストCPUの範囲はコア内部に限られ、2つの物理コア間を移動することはできません。
通常、コアと同じサイズのチャンク単位でCPUを割り当てるのが最善策です(ホストでpsrinfo -vp
を確認してください)。
デフォルトでは、dedicated-cpu:ncpus
の設定によって、どのホストCPUが割り当てられるかを制御することはできません。そのため、ホストの再起動の前後でCPUの割当て状態が一貫しない場合があります。したがって、dedicated-cpu:cpus
によって、利用するCPUを正確に指定することをお勧めします。
また、特定のレイテンシ・グループからCPUを指定するといいでしょう。たとえば、基盤のネットワーク・デバイスと同じレイテンシ・グループを用いることで、ネットワークのパフォーマンスが向上することがあります。
root# dladm show-phys LINK MEDIA STATE SPEED DUPLEX DEVICE ... net8 Ethernet up 10000 full ixgbe0 ... root# lgrpinfo -d /dev/net/net8 lgroup ID :1 root# lgrpinfo -G -c 1 lgroup 1 (leaf): CPUs:0-9 40-49
ホストのnet8
データリンク上に自動ネットワーク・リソース(anet)を作成するには、0~9または40~49の範囲でCPUを割り当てるといいでしょう。
virtual-cpu
リソースの設定によって、ゲスト・カーネルに示される仮想CPU数を指定できます。ホスト上では、仮想CPUはオペレーティング・システム・スレッドに対して同じように振る舞います。仮想CPUは、大域ゾーンを含む他のゾーンのスレッドとCPU時間を共有します。仮想CPUは、統合率を最大化するための最良のオプションですが、パフォーマンスに影響が出る可能性があります。
カーネル・ゾーンではanetを利用することをお勧めします。他のゾーン設定と同様に、anetのセキュリティ設定を適切に行ってください(allowed-address
、link-protection
など)。
ネットワーク・デバイスと同じレイテンシ・グループをカーネル・ゾーンが利用するように構成するといいでしょう(上記を参照)。
デフォルトでは、カーネル・ゾーンのインストールで、起動ディスク用に16GBのZFSボリュームが利用されます。16GBのルート・プールで十分ではない場合は、インストール時に次のコマンドを実行して異なるサイズを指定できます。
# zoneadm -z kzone install -x install-size=32g
ただし、ZFSボリュームには"実際の"ディスクほどのパフォーマンスはありません。また、複数のシステム間での移植性はありません。
そのため、実際のディスク・デバイスを指定すべき状況も多くあります。実際のディスク・デバイスとしては、ホストに直接接続されたLUNを利用できます。また、異なるホスト間の移植性が要求される場合はiSCSIディスクなどを利用できます。"共有ストレージ上のゾーン"(ZOSS)URIを利用して、たとえば次のように共有ストレージを指定します。
# zonecfg -z kzone info device id=0 device: match not specified storage: iscsi://iscsi.server/luname.naa.600144F0CBF8AF19000051B06914000A id:0 bootpri:0
ルート・プールに参加しないストレージをカーネル・ゾーンに追加する場合は、かならずbootpri
プロパティをクリアしてください。
カーネル・ゾーンの一時停止/再開機能を有効にするための一時停止リソースを構成する場合、カーネル・ゾーンの最大メモリ・サイズと数メガバイトを加えた十分な容量が、構成するストレージに残っていることを確認してください。
イメージをホスト・システム上に保存する場合は、次のように、すべてのブート環境により共有される領域を利用します。
... zonecfg:kzone> select suspend zonecfg:kzone:suspend> set path=/export/zones/%{zonename}/suspend.img zonecfg:vzl-100> exit # mkdir -p /export/zones/vzl-100/ ...
ホスト間のウォーム・マイグレーションを行う場合は、両方のホストから同じパスで一時停止ストレージにアクセスできるようにしてください。たとえば、上記に示したZOSS URIを利用したり、両方のホスト・マシンで同一のNFSパスを指定したりすることができます。
関連資料:
その他のOracle Solaris参考資料:
John Levonは、Oracle Solaris VirtualizationグループのPrincipal Software Engineerです。イギリス在住で、10年以上にわたりOracle Solaris開発に従事しています。
リビジョン1.0、2014/12/29 |