Solaris SPARC Private Cloud(SSPC)のOSコンパチビリティガイド(リフト移設時のバージョンガイド)

Solaris SPARC Private Cloud(SSPC)コンパチビリティガイド

当社のSolaris SPARC Private Cloud(SSPC)で利用しているSPARCハードウェアは、最新版となるSPARC M8、あるいはS7になります。
以下の表はSSPCへのリフト移設時のOSコンパチビリティです。

ご利用中のOS version?			クラウドへリフト移設後のゲストドメインOSバージョン	移設方法	リフト可否
メジャー	マイナー	リリース名	クラウドへリフト移設後のゲストドメインOSバージョン	移設方法	リフト可否
Solaris 8			Solaris 10(最終版)上でLegacy Zone(※1)	Flash Archive	△
Solaris 9			Solaris 10(最終版)上のLegacy Zone(※1)	Flash Archive	△
Solaris 10		1/05	(※2) Solaris 10 1/13 + Recommended CPU 2018-01以降あるいは、 Solaris 11.4上のSolaris 10 Legacy Container	Flash Archive	○
	u1	1/06			○
	u2	6/06			○
	u3	11/06			○
	u4	8/07			○
	u5	5/08			○
	u6	10/08			○
	u7	5/09			○
	u8	10/09			○
	u9	9/10			○
	u10	8/11			○
	u11	1/13			◎
Solaris 11	11	11/11	11.4上で再インストールしていただく必要があります。(※3)	なし	×
	11.1	10/12	11.4上で再インストールしていただく必要があります。(※3)	なし	×
	11.2	4/14	11.4上でKernel Zoneでの移設	Unified Archive	○
	11.3SRU9未満	10/15	11.4上でKernel Zoneでの移設	Unified Archive	○
	11.3SRU9〜23		アップデート無しで動作可(SPARC S7以降)	Unified Archive	◎
	11.3SRU24〜		アップデート無しで動作可(SPARC M8以降)	Unified Archive	◎
	11.4		アップデート無しで動作可	Unified Archive	◎

※1 Solaris8/9のリフトは、Solaris10(最終版)の上にLegacy Zone(コンテナ)としてで移設、動作が可能になります。ただしカーネルはSolaris10となるため、カーネル依存のソフトウェアは動作しない場合があります。

※2 Solaris 10をFlash Archiveを用いて移設する際には、2つの方法を選ぶことができます。1つめの方法はSolaris 10 カーネルを利用する方法と、Solaris 11のカーネルの上でSolaris 10 Legacy Zone利用する方法です。どちらの方法でもSolaris 10のパッケージイメージは、最終版の1/13に、最新のCritical Patch Unit(CPU)が当たった形となります。Solaris 10カーネルを用いた場合は互換性が高くなり、カーネルモジュールの動作が保証され、基本的には全てのソフトウェアの互換が保たれますが、2025年1月でメーカーのExtend Supportが終了されます。一方、Solaris 11.4のカーネルの上でSolaris 10 Legacy Zoneで動かす場合のEoLは、定められていません(カーネルの11.4が最低2034年とアナウンスされています)。詳しくは、下記「Solaris10のマイグレーション手法比較表」を参照してください。

※3 11/11.1には、システムのアーカイブ手法がありません。

Solaris10のマイグレーション手法比較表

	Solaris 10カーネル	Solaris11.4カーネル上のSolaris 10Zone
実装	Oracle VM Server for SPARC(LDOM)に、最終版のSolaris10 1/13+最終版Critical Patch Unit適用済インスタンスを作成	Oracle VM Server for SPARC(LDOM)に最新版のSolaris11.4インスタンスを用意、Solaris10 Zoneを作り最終版のSolaris10 1/13適用済みインスタンスを作成)
カーネル	Solaris 10	Solaris 11.4
速度	○	◎
互換性	◎(カーネルモジュールの動作が可能)	○
メモリリソース	◎	○
リフト移設の手法	Flash Archiveで移設	Flash Archiveで移設
保守期限	2025.01	2034年
価格	△ (Critical Patch Unit利用料金が必要)	○

よくある質問

OSバージョンごとのクラウド移設（リフトによるマイグレーション）時のよくある質問です。

▼Solaris 10 / ▼Solaris 11/Solaris11.1 / ▼Solaris 11.2/Solaris11.3 / ▼Solaris 11.4

Solaris SPARC Private Cloud(SSPC)コンパチビリティガイド
Solaris10のマイグレーション手法比較表
よくある質問

利用しているSolarisのバージョン確認方法を教えてください

下記からは、Solaris 10 1/13と言うことが把握できます。

# cat /etc/release	
                   Oracle Solaris 10 1/13 s10s_u11wos_24a SPARC	
  Copyright (c) 1983, 2013, Oracle and/or its affiliates. All rights reserved.	
                            Assembled 17 January 2013

参考≫細かなパッチバージョンの調査方法

下記からは、Solaris 11.4と言うことが把握できます。

# cat /etc/release
                            Oracle Solaris 11.4 X86
            Copyright (c) 1983, 2020, Oracle and/or its affiliates.
                          Assembled 23 September 2020

参考≫Solaris 11のマイナーバージョンを調べる方法を教えてください。

Solaris 10

Solaris 10の細かいパッチバージョンをしらべる方法を教えてください。

# showrev
Hostname: xxxxxxx
Hostid: *******
Release: 5.10
Kernel architecture: sun4v
Application architecture: sparc
Hardware provider: Oracle Corporation
Domain:
Kernel version: SunOS 5.10 Generic_150400-59

150400-59のパッチが当たっていることがわかります。ここからSolaris 10のどのバージョンのCPU(Critical Patch Unit)が当たっているのか、実際のパッチリストから調べることができます。

アップデートを行わず、Solaris10を移設することはできませんか？

当社のSSPCで利用しているSPARCハードウェアは、最新版となるSPARC M8、あるいはS7になりますが、最終版のSolaris10 1/13がリリースされた以降のハードウェアである為、少なくてもSPARC S7においてはCritical Patch Unit(CPU) 2015.10を、SPARC M8の場合はCPU 2017.06以降を当てる必要があります。そのためリフト移設後のOSバージョンは、事実上、最新のSolaris10にアップデートされることになります。リフト移設時にはオンプレミスのOS環境を破壊して移設する必要は無いため、現状の環境に手を入れることなく、リフト移設と同時に「OSアップデート時でソフトウェアが問題なく動くのか？」をテストすることができます。

Solaris 10の利用は、Solaris 10カーネルを利用する方法と、Solaris 11.4の上でLegacy Zoneを使う方法、どちらが望ましいですか？

まずは「Solaris10のマイグレーション手法比較表」をご参照ください。Solaris 10はメモリが1GB程度しかない時期のOSであり、現在のSPARCシステムのカーネル動作は多くのパッチが当たった状態での動作となっています。そのため、現在のハードウェアを効率的に利用できず、互換を重視した動作となります。(イメージで言えば、現在のパソコンで、Windows XPにパッチを沢山当てて起動させるようなものだと思ってください)。またクラウドにリフト移設したとしても、OS自体のパッチは、2025.1に最終パッチがでたあとで終わってしまいます(クラウド上の動作は続けられますが別の手法でセキュリティを保っていただく必要はあります)。そのため、当社からもっとも勧められる手法は、Solaris 11.4の上でSolaris 10 Legacy Zoneを先ずは一度試してみることをお薦めしています。このとき、クラスタリングソフトウェアなどを同時にアンインストールすることをお薦めします。システムの動作においてカーネルモジュールなどがあり、どうしても動作しない場合のみ、Solaris10カーネルをご選択ください。

なお、移設手法については、SPARC Solaris 8/9/10のP2V/V2Vマイグレーション(Zone編)をご覧下さい。

Solaris 10で動いてる実機は2GBで動いていました。SSPC上ではどのぐらいのメモリを確保するべきでしょうか？

Solaris 11.4の最低実行環境は8GBであり推奨は16GB程度が必要です(Windows11ぐらいの動作環境だと思って下さい)。この上にSolaris 10のLegacy Zoneを動作させることを考えると、2GBで動いていた環境でも16GB程度の用意が必要となります。

仮にSolaris 10カーネルのまま移設した場合でもあっても、初期のSolaris 10の2005年版の動作環境に比べると、最終版のSolaris 10の2013年版の動作には、多くのカーネルメモリを必要とします。

またSSPCではファイルシステムがZFSを用います。ZFS自体は旧来のUFSに比べると、ディスクキャッシュに大変多くのメモリを利用します。キャッシュは概ね搭載メモリの半分ぐらいを利用し、推奨されるキャッシュ容量は、概ね利用ストレージサイズ合計の、およそ1/512程度のメモリは必要です(1TBの場合は2GB、10TBの場合は20GB程度のディスクキャッシュを利用します)。

FujitsuのSPARC64シリーズを利用中ですが、InfiniCloudのSSPCにリフト可能ですか？

可能です。

Fujitsu SPARC64シリーズからのマイグレーション移設は、実際に多数行われています。ただし、実際のシステムにおいて、クラスタリングツールや、いくつかの特殊なものが含まれる場合は、事前にアンインストールする必要があります。

参考≫ 稼働系で事前アンインストールをすることは避けたいのですが、これをクラウド上でおこなうことはできますか？

稼働系で事前アンインストールをすることは避けたいのですが、これをクラウド上でおこなうことはできますか？

可能です。

たとえば、Flash Archive内に富士通SPARC 64専用のカーネルモジュールが含まれていたり、Veritasのクラスタリングツール等、クラウド上で動かないものが存在するケースがあります。この場合、Flash Archive展開後のOSの初期ブートが正常にできないことがあります。

Solaris10をSolaris11.4のLegacy Zoneとして動かす場合は、Flash Archiveを用いてZoneを作成後に、zloginでログインを行い、直接不要パッケージが削除できます。(※カーネルモジュールは自動的に破棄されるため) 後は、サービス起動に不要な物を削除することで移設が完了します。

Soalris10カーネルで動作させる場合、SolarisのLive CDで起動を行い、不要な物を削除する必要があります。

一旦、SSPC上のインスタンス(LDOM)にコンソール接続(VPN接続後、telnetが必要)
Okプロンプトにて、OSをcdromイメージからOSブート。
flarを展開したルートボリュームをマウント(/mntなどにマウントする)。
pkginfo -R /mntでパッケージのリストを出力。
不要な物は、pkgrm -R /mntなどを用いて削除を行う。
/mnt/etc/systemファイルで、不要なカーネルに関連するドライバがあればコメントアウトする。
/mnt/etc/vfstabファイルで、不要なマウントポイントがあれば、一旦コメントアウトする。
ブートに必要であればpkgadd -R /mntなどを用いてインストールする。
bootadm update-archive -R /mntで、ブートアーカイブを作りなおす

この操作を繰り返すことでなるべくシンプルな状態にして起動を行います

ファイルシステムをufsのまま、移設することは可能ですか？

制限があり、推奨しかねます。

ufsでflarが展開された物は、ESB(Enterprise Storage Block)を片系しか使う事はできません。

この場合、Solaris Live Upgradeを利用し、ZFSのファイルシステムにブートイメージを移設する必要があります。移設後、複数のESBをZFSで利用することで、ストレージの冗長性担保が可能です。

ZFSに変更する場合、リソースはどの程度の余裕が必要ですか？

ZFSには、スナップショットやクローン、圧縮、暗号化、など様々な魅力的な機能だけでなく、データの安全性にも定評があるファイルシステムです。最大の特徴は、CoWの構造上、基本的にはfsckが要らないことなども上げられます。

かわりに「メモリやディスクが潤沢にある」ことを前提に設計されているため、CPUコアの余裕、メモリの余裕、ストレージの余裕が十分に必要になります。

具体的な数字は利用シーンによって異なりますが、メモリに関してはSolaris 10で動いてる実機は2GBで動いていました。SSPC上ではどのぐらいのメモリを確保するべきでしょうか？を参照いただき、ストレージ容量に関しては、概ね、2〜3倍程度の容量を想定しておくことが無難となります。

これは、ZFSがデータロストなどがないようにCopy On Writeを利用しており、安全性側に余裕をみている為に発生します。

レコードサイズ: UFSは8kですが、ZFSでは128kがデフォルトです。データサイズをレコードサイズで割り、あまりのレコードサイズ未満のデータは全てパディング(レコードサイズの量)になります。
スナップショット: クラウド化の時、様々な状態で試行錯誤を行う場合があります。その際、現時点のスナップショットを取って以前の状態を保全したり、ZFSによって拡張されたLive Upgradeの機能であるlucreateコマンドとluactivateを利用し、「起動環境」を複数持つことができます(カーネルをSolaris10にした場合、solaris10 zoneの場合はzone毎Snapshotを取ることができます)。
クローン: スナップショットを元に、データのクローンが可能です。
CoWとデータの遅延削除: ZFSが採用しているCopy On Write型のファイルシステムは、ファイルの更新がある時、レコードサイズ単位で新しい場所に書き換えたデータをコピーして格納し、元のデータ箇所を開放する手法です。従来のRead Modify Write方式では、同じ場所に書き換えデータを保存するため、その瞬間にシステム障害が起きると、そのデータが失われてしまいます(これがfsckなどが必要とする理由の1つです)。Read Modify Write方式は、ストレージの容量効率は良いものの安全性は低く、CoWは安全性が高いかわりに、開放タイミングまでの間は書き換えデータと元のデータは両方ディスクに保存されていることになります。解放処理はストレージが忙しくないタイミングに行うため、読み書き、書き込みの頻度が多いシステムでは空き容量がなかなか解放されないこととなります。

一般に、ファイルシステムはデータを格納する際に連続した領域に保存することで読み書きの速度を上げるように設計されています。しかし、ファイルの更新が行われる度に、フラグメンテーション(ストレージに対するデータ配置の連続性。例えばNTFSでのデフラグはフラグメンテーションを排除するツールです)などが起きにくいようにするため、なるべく連続したストレージの領域にファイルが配置されるように、空いた場所を探しながら配置をするアルゴリズムをもちます。しかし、ストレージの使用率が上がるほど、フラグメンテーションが起きない場所に配置する事が難しくなるため、ZFSではある段階で、このアルゴリズムを「最速一致」から「最良一致」に変更する構造を持ちます(このような連続配置の仕組みはZFSに限らず様々なファイルシステムが似た構造をもちます)。

アルゴリズムが最速一致から最良一致に変わる時、空いた場所の検索をする負荷が格段に上がり、書き込み速度が顕著に悪化しはじめます。

このタイミングはストレージの利用率によって判断され、Solaris10カーネルでは80％、Solaris11カーネルでは90%で発生するため、事実上これを死守ラインと考えていただき、監視ラインをSolaris10では7割、Solaris11では8割にすることをお薦めしています。

以上のように、ストレージサイズには余裕が必要になるため、2〜3倍を想定しながら、十分な容量の割当を行ってください。

参考≫ Solaris 10の場合(英語) https://docs.oracle.com/cd/E26505_01/html/E37384/zfspools-4.html#storage-8
参考≫ Solaris 11の場合(日本語) https://docs.oracle.com/cd/E75431_01/html/E75197/zfspools-4.html#SVZFSstorage-8
参考≫ Solaris 11の場合(英語) https://docs.oracle.com/en/operating-systems/solaris/oracle-solaris/11.4/manage-zfs/storage-pool-practices-performance.html#GUID-3568A4BD-BE69-4F17-8A2E-A7ED5C7EFA79

Solaris 11/Solaris11.1

Solaris 11のマイナーバージョンを調べる方法を教えてください。

Solaris 11のマイナーバージョンは下記のコマンドでわかります。下記からは、Solaris 11.4のSRU 6であることがわかります。

# LC_ALL=C pkg info entire
          Name: entire
       Summary: entire incorporation including Support Repository Update (Oracle
                Solaris 11.4.6.4.0).
   Description: This package constrains system package versions to the same
                build.  WARNING: Proper system update and correct package
                selection depend on the presence of this incorporation.
                Removing this package will result in an unsupported system.  For
                more information see:
                https://support.oracle.com/rs?type=doc&id=2433412.1
      Category: Meta Packages/Incorporations
         State: Installed
     Publisher: solaris
       Version: 11.4 (Oracle Solaris 11.4.6.4.0)
        Branch: 11.4.6.0.1.4.0
Packaging Date: Fri Feb 01 21:46:04 2019
          Size: 2.52 kB
          FMRI: pkg://solaris/entire@11.4-11.4.6.0.1.4.0:20190201T214604Z

solaris11-cpu(Critical Patch Unit)が適用される場合は、下記のコマンドで調べることができます。下記からは、Solaris 11.4のCPU 2020.05を利用していることがわかります。

# LC_ALL=C pkg info solaris-11-cpu
             Name: support/critical-patch-update/solaris-11-cpu
          Summary: Oracle Solaris 11.4.21.69.0 Critical Patch Update 2020.5-1
      Description: This package ensures a system remains up to date with the
                   Oracle Critical Patch Updates for Oracle Solaris
            State: Installed
        Publisher: solaris
          Version: 2020.5
           Branch: 1
   Packaging Date: Mon Apr 27 15:44:13 2020
Last Install Time: Sun Oct 27 13:59:00 2019
 Last Update Time: Wed Jun 10 11:15:30 2020
             Size: 2.52 kB
             FMRI: pkg://solaris/support/critical-patch-update/solaris-11-cpu@2020.5-1:20200427T154413Z

SRU(Support Repository Update)とCPU(Critical Patch Unit)には、下記の違いがあります

SRU: 毎月の頻度で、バージョンアップされます。パッチのみでなく新機能の追加も行われます。
CPU: 四半期に一度、SRUとほぼ同じバージョンへとアップデートされますが、次の四半期までに存在するOSの問題はクリティカルなものだけバックポートされます。

Solaris 11/Solaris 11.1の場合、リフト可能ですか？

できません。先ずは実機で最低限、Solaris 11.2までは上げる必要があります。しかしながら動作中のシステムのアップデートは難しいと思われるので、SSPC上で再セットアップをする事をお薦めしています。

Solaris 11/Solaris 11.1可動中システムのインストール手順書が完全に失われており、再インストールが不可能です。どうしてもリフト移設を行いたいのですが、他に方法はないですか？

できません。しかしながら、Solaris 11の場合は、ZFSが標準で使われています。ZFSの場合はrpoolのSnapshotを作成し、zfs send とzfs recvを行う事で、イメージを移設することが可能です。そのzfsイメージをSSPC上にrecvを行い、zonecfgを正しく書くことで、zoneadm -Uでアップデートインストールする事が「可能な場合」があります。ただし、IPSのconsolidation packageのエラーが出る可能性が多く、この場合は、いくつかのpkg -R /path/to/zoneでfacetの設定、不要なもののアンインストールをすることで、移設が可能になる場合があります。

Solaris 11.0/Solaris11.1可動中システムのインストール手順書が完全に失われており、zfsで持っていったのですが、どうにも動かすことができません。

残念ですが、SSPCの上のSolaris11.4でSolaris11.4のzoneを作り、11/11.1のpool群をマウントし、OS外の必要なソフトウェアファイルをコピーすることができれば、動作させることが可能性が高いと考えられます。Solarisのバイナリ後方互換性は非常に高いため、それで稼働できるケースも多々あります。

Solaris 11.2/11.3

Solaris11.2や11.3はどのようにSSPCに移設可能ですか？

可能です。まずは実機上、既存システムにてarchiveadmを利用してUnified Archiveを作成し、そのアーカイブをSSPCのSolaris 11.4に転送してください。

Solaris11.4にて、Kernel Zoneを作成しUnified Archiveを利用してデプロイします。

ただし、11.2/11.3はOSの保守期限が切れており、そのままの利用は推奨されておりません。可能であればZoneのclone機能を利用し、11.2/11.3から、11.4の最新版までアップデートを試みることをお薦めします。

Solaris11.4

Solaris11.4SRU24未満ですが、移設は可能ですか？

可能です。まずは実機上、既存システムにてarchiveadmを利用してUnified Archive を作成し、そのアーカイブをSSPCのSolaris 11.4に転送してください。

Solaris11.4にて、Kernel Zoneを作成し、Unified Archiveを利用してデプロイします。

ただし、Zoneのclone機能を利用し、11.4の最新版までアップデートを試みることをお薦めします。