FujitsuのSPARC64シリーズからの移設
- FujitsuのSPARC64シリーズ(M3000/M5000/M8000、M10/12)からの移設について
- M3000/M5000/M8000シリーズからの移設
- M10/M12シリーズからの移設
- SPARC64から移設後にCPU律速が見られた場合
FujitsuのSPARC64シリーズ(M3000/M5000/M8000、M10/12)からの移設について
Fujitsu SPARC64シリーズからのSolaris SPARC Private Cloud(SSPC)への移設実績は多数あり、熟れた移設とも言えます。
しかし、実際のシステムにおいて、クラスタリングツールや、いくつかの特殊なものが含まれる場合を事前にアンインストールする必要があります。
参考≫ 稼働系で事前アンインストールをすることは避けたいのですが、これをクラウド上でおこなうことはできますか？
また、事前の性能予測として大切なこととして、Solaris SPARC Private Cloudで利用しているCPUはS7/M8となるため、CMT型（チップレベル・マルチ・スレッディング）のプロセッサであることです。
SPARC S7/M8は1Coreで8Threadsを動かすCMT構造をもち、8vCPU毎で「1コア」です。したがって、オンプレミスの環境で合計20コア使っているのならば、SSPCでも同じコア数、20コア、すなわち、160vCPU(Threads)を用意する方が無難です。
M3000/M5000/M8000シリーズからの移設
M3000/5000/8000世代は、総じてSSPC S7モデルでも十分な性能を出すことができ、その大半でオンプレシステムよりも高速化される傾向があります。しかし極一部で、シングルスレッド性能が奮わなくなる可能性もあります。
また、バイナリタイプが異なるため、flash archive作成時にsun4vを指定する必要があります。
例
# flarcreate -n solaris10 -c -L pax solaris10.flar -U "content_architectures=sun4c,sun4d,sun4m,sun4u,sun4us,sun4s,sun4v"
M10/M12シリーズからの移設
M10モデルの場合は概ね、同じコア数をS7モデルで選べば問題はないのですが、M12モデルはSPARC64 CPUとしては集大成のCPUであるため、SSPC T8モデル(CPUにM8を採用)を選択する方が良いでしょう。
ただし、CPUクロックや並列での実行速度はS7/M8モデルの方が速いため、アプリケーションがマルチスレッド、マルチプロセスか、シングルスレッド性能に委ねられているか？がキーポイントとなります。
CPU律速であるかどうかは、簡単に調べることができます。
prstat -mL 1
コマンドを入力すると、画面にプロセスの一覧が現れますが、そのうち、特定プロセスのUSRが100％近くなっていた場合は、CPU律速になっているシステムだと言えます。この場合は、SPARC T8モデルを選択する方が無難です。
逆に、負荷がかかってる時間帯でも、ご利用中のオンプレミスシステムにおいて、このような事象が無い場合、S7モデルに移設しても問題はおきにくいと言えるでしょう。
またこのコマンド内でSYSが多い場合、SYSCALL発行内での律速が考えられます。SYSCALL内の律速は、IO速度や、OSのチューニングなどにより、改善することも考えられます。
実機での速度に比べ、SSPCはICSを利用したNVMeでのストレージモデルや、10G/25GなどのNICを選ぶこともできるため、周辺クラウドシステムを慎重に選ぶことにより、SSPC移設後に高速化できる可能性も高いと言えます。
SPARC64から移設後にCPU律速が見られた場合
上記に注意して選ぶことでほとんどのケースで律速問題がでることは少なくなりますが、実際に移設をして、思わぬところでCPU律速がおきた場合、次のような回避手法もあります。
まず、前提として、SPARC S7/M8は1Coreで8Threadsを動かすCMT構造をもち、8vCPU毎で「1コア」です。したがってコア数の割当をきちんと確認する必要があります。
結果的に仮想サーバ内でスレッド数が多く見えますが、ワーストケースでは1Threadあたりの性能は単純にTime Share Schedulingをすると1Thread(vCPU)=1/8Coreの性能になってしまいます。CMTはIntelプロセッサでいうところのHyper Threadingに近い技術ですが、コンテキストの切替手法は異なります。一般に、CPUの速度に対してメモリはとても遅いのが普通です。S7/M8は、CPUが呼び出そうとするコンテキストが参照するメモリがキャッシュに乗っていなければ、コンテキストを切り替え、キャッシュレーンに乗っているスレッドを優先的に実行したりすることで、CPUを効率的に使っています。実行演算器もコアに1つというわけではないため8つのスレッドが1つのコアで上手く動くようにスケジューリングされますが、コア単位でしか専有できないリソースもある為、CPU律速がおきる場合はこの様なリソースにアクセスしている可能性もあります。
また、SolarisにはデフォルトでFSS(Fair Share Scheduler : 公平配分スケジューラ)という方法で、UNIXのスレッド処理を「よく使う物に優先的に当てはめ、他のものが使うときにはそちらにも上手く回す」というようなスケジューラが実装されています。
この手法はマルチスレッドアプリケーションには上手く動きますが、シングルスレッドで重い処理を行うアプリケーションは不向きになります。そこで、prstat -mLコマンドなどでCPU利用率の調査を行い、特定のプロセスのUSRが100％近くになっているのならば、CPU律速と判断し、そのスレッドをクリティカルスレッドとして扱う方が良いでしょう。
クリティカルスレッドの指定は、
sudo prioctl -s -c FX -m 数字 -p 数字 -i pid <PID>
などで行う事ができます。
詳しくはOracle社のマニュアルをご参照下さい。
