自宅のLabを新しくした話(サイジング編 )

今回は、自宅Labを強化しました。というお話で、日記的な随筆的なタッチで駄文を書きながします。

背景

以前、Red Hat Tech Night のLTで、『みんな持ってる自宅Lab』のオンプレクラウド系インフラエンジニアが自宅にLabを作る上でのツラミについてお話しました。
Red Hat OpenStack Platform やRed Hat OpenShift Container Platform は、Red Hat が言う構成で動かそうとすると、とってもとってもマシンリソースが必要だ。というお話でした。
私は、プロダクトの動きであるとか、それがもたらす効果といった事を、色々な方に伝える為に、多くの事を正しく理解する必要があると捉えています。しかし、製品のマニュアルや説明資料を読んでいるだけでは、なかなか理解できなくて、それを補う為に、自分で実験しながら少しずつ理解を深めるアプローチを取っています。
いつでも自分の一存で好き勝手できる環境が最も都合が良いので、自宅のPCを使って...という発想になるわけですが、最近のクラウド系プロダクトは、ハードウェアの要件が厳しくて、ここ2年くらいは、自宅のLabでの実験については、色々な物を諦めつつ、限定的な内容にとどめていました。

契機

2020年、新年早々、同僚らと会話していたところ、「最近は、IvyBridge世代のワークステーションが充実している。」という話題になり、Intel Xeon 2 socket で、3桁GBのメモリを搭載した中古マシンを、新品のMAC Book Pro を購入する価格帯で、手に入れられるんだと知りました。
Tech-Night LTで話した、”嫁稟議”がいよいよ現実的になってきたわけです。
実際に、中古の市場で探してみると、8万円前後で、64GBメモリ搭載のマシンというのは、沢山あって、過去に探した時よりは選べそうだなと感じました。
丁度、趣味の都合で、Mac Book Proを購入しようとしていたところに、これまたなんとも興味を惹かれるテーマが舞い込んできたなという感じです。

獲物

なんやかんや天秤に掛けながら、いよいよ本気で欲いマシンを探してみる事にした訳ですが、買うにしてもどの程度のスペックがいいのか一度、整理してみました。
まず、動かしたいプロダクトは以下となります。

• Red Hat OpenStack Platform
• Red Hat OpenShift Container Platform
• Red Hat Ceph Storage

これらの製品をフルサポートの前提で構築するなら、RHOSP 、RHCS は、それらを構成するサーバのほとんどを物理サーバで構築しなくてはなりません。しかし、流石に物理マシンを何台も並べるというのは、一般家庭で電力をまかなえる気がしないの（というかそういう発想はしないの）で、KVM上にこれらの環境を作る作戦にします。
作りたい環境を図に示すと下図の様になります。

この構成を実現するうえで、リソースが大量にあれば、それに越したことはありませんが、現実的な金額でなければ、嫁から「買ってOK」はもらえないので、各製品の最低スペックをベースに、ざっくりサイジングをしていくことにします。

RHOCP

OpenShift は、OpenStack 上のテナントとして作れることを目指します。所謂、OpenShift on OpenStack 構成です。
現在ですと、OpenShift 4.2 , 4.3 あたりがターゲットのバージョンとなるので、基本的な構成は、Master node 3台、Worker node 3台以上となります。

サーバリソースの観点では、下記のスペックが最低ラインとして設定されています。

リソース	スペック
vCPU	28
RAM	112GB
ボリュームストレージ	175GB

このリソースと、bootstrap(OCPインストール時のみ必要) , master , worker に割り当てるイメージになります。製品マニュアルには、各ノードに、4vCPU、16GBメモリ、25GBのストレージ とあるので、期待しているOpenStack のフレーバー(flavor) は、

今回の記事と全く関係ないです...
$  openstack flavor create --disk 25 --vcpus 4 --ram 16384 --public 4c16g25d

のようにつるんだろうな〜と想像しつつ、サイジングを進めます。尚、OpenStack 上で、動かしたいので、OpenStack のcomputeノードは、少なくとも、ゲストに対して割当可能なリソースを持っている必要があります。
OpenStack compute ノード上でのゲストインスタンスの配置を考えると、下記の様な作戦が考えられます。

コンピュートノード数	一台あたりゲスト(OCPノード)数	必要リソース合計	備考
1	7	vCPU:28 RAM:112 + 2GB	computeノード障害のような試験は不可
2	4	vCPU:32 RAM:128 + 4GB	computeノード障害を起こす時は、masterノードが1つだけ引きずられるマシンを選ぶこととなるが、その場合、worker ノードは、2台引きずられるため、アプリケーションの試験までは出来無い可能性がある.
3	3	vCPU:36 RAM:144 + 6GB	必要充分なテストができそうだが、OCP 2ノード分のリソースが余る
4	2	vCPU:32 RAM:128 + 8GB	compute 3台よりリーズなブル。OCP 1 ノード分のリソースが余る
5	2	vCPU:40 RAM:160 + 10GB	OCP 3 ノード分のリソースが余る
6	2	vCPU:48 RAM:192 + 12GB	OCP 5 ノード分のリソースが余る
7	1	vCPU:28 RAM:112 + 14GB	compute:node が 1:1 但し、openstack computeノードを作るごとにそのRAMとHDDがオーバーヘッドとして必要となるため、もったいない

ということで、構成上のリソース利用効率（ケチれるならケチる）と、実験したいことと照らし合わせると、compute ノードを4台つくれるというのが一番ばバランスが良さそうです。
このことを根拠に、RHOSP のコンピュートノードのスペックの目安として、下記を用意できればいいかなとなります。

リソース	スペック	暫定合計
vCPU	8	32
RAM	34 GB	136 GB
HDD	60 GB	240 GB
compute は、4台で構成

OpenShift on OpenStack の構成に関する詳細は、Red Hat OpenShift Container Platform 製品マニュアルを参照をご覧ください。

RHOSP & RHCS

次に、Red Hat OpenStack Platform について見ていきます。先に述べた、compute ノードに加えて、RHOSPでは、もっとも一般的な構成(コントロールプレーンの冗長でかつ細かく機能は分離しないの構成）を前提とすると、以下のノードが必要となります。

• director x 1 (RHOSPの構成管理マシン)
• controller x 3 (RHOSPのコントロールプレーン)

製品マニュアル(RHOSP13)に示されているスペックは、下記となります。

役割	CPU	RAM	HDD	台数	備考
director	8 core	16GB	100GB	1
controller	NA	32GB	40GB+α	3	CPUは記載がないので2コア HDD+α=Object Storage(swift)の容量

製品マニュアル:directorのシステム要件
製品マニュアル:controllerのシステム要件

続けて、Red Hat Ceph Storage(RHCS) について考えていきます。
RHOSPコントローラを冗長構成とした場合で、共有ストレージが無い場合は、Controllerの内蔵ディスクに、Volume ( cinder-volume) が配置されます。Volume サービスは、排他（controller3台のうち1台でアクティブな）制御となるサービスのため、フェールオーバーが発生すると領域が見えなくなってしまいます。また、該当の領域をレプリケーションする機能は製品的には提供されていません。
これだと、思い通りの試験ができない可能性があるため、共有ストレージ領域となる物を用意こととします。
ここで共有ストレージ用に、NFSサーバという選択肢も考えますが、『大は小を兼る。』というのと、RHCSの動作についても深く観察したい気持ちもありますので、RHCSを動かせるなら、それがいいかなと思います。

RHCSは、大きく以下のコンポーネントがあります。

• MON
• OSD
• MGR
• MDS
• RDSGW

RHOSPのバックエンドとする場合、MON とMGR は、controller上で稼働させることができるため、検討対象から外します。
また、MDS については、CephFSを使用する時に必要となりますが、OpenShiftと同時に使用するシナリオは今のところ思いつかないので、CephFSを動かしたい場合は、遣り繰りでなんとかすることにします。
RDSGWは、RHCSのRHOSPバックエンドというシナリオだと、Object Storage(swift)のバックエンドとする場合に必要となりますが、これについても、OpenShiftまで含めての同時に動かす必要が今のところ思いつかないので、検討の対象から外します。
よって、考えなくてはならないのが、OSD のサイジングとなります。

OSDは、ストレージサーバ上で起動させるOSDプロセスの数(搭載するHDDの本数）をベースにサイジングする形となります。尚、ここでも最低限動けばよい前提ではあるものの、データの可用性については、デフォルトの 3 レプリケーションとしたいので、ストレージサーバは、3台構成として、サーバ一台あたり、2〜3のOSDを稼働させるような目標感でサイジングしていきます。

ストレージサーバ 一台あたりのスペックの考え方は、以下となります。

リソース	スペック
CPU	1 / osd
RAM	16 GB + 5 GB / osd
HDD (root)	NA

製品マニュアル:ceph最小要件

尚、ストレージサービスとしての容量は、RHOSPのバックエンドに、RHCS を配置した場合、ゲストVMのブートディスクがRHCS上に配置されます(cinder bootとなる)。というのと、OpenShift で、Persistent Volume ( コンテナの永続ボリューム )や、Container Registoryの保存領域として、OpenStack cinder が使用されます。なので、ストレージサービスの容量をざっくり見積もると、下記のようになります。

対象	容量
ゲストVM	25GB * 7 = 175 GB
Container Reg	100 GB
Persistent Vol	100 GB

ストレージサービスとして、375GB に、安全率をなんとなく、20%程度見込んで、およそ500GBの領域を作ります。
OSDを沢山動かすと、メモリをそれだけ必要としますので、理想的には、100GB * 5osd ですが、今回は、
200GB * 3osd のあたりを想定しようと思います。尚、RHCOSは、Blue Store も試したいので、600 GB のうち、10％は、オーバーヘッドとして使用されます。

RHCOSに必要なリソースをまとめると、

リソース	スペック
CPU	3コア
RAM	16 GB + 15 GB = 31GB
HDD (root)	NA
HDD (osd )	200GB * 3

storageサーバは、3台で構成

となります。

自宅ラボに欲いスペックのまとめ

KVM上に実験環境を作る作戦としていますので、KVMゲストのサイジングを元に、必要となるスペックを算定します。尚、厳密には、vCPUとCPU core は別の事をさしますが、仮想化するので、乱暴ですが、同様の指標として扱います。

ゲスト	CPU	RAM	HDD	台数	小計CPU	小計RAM	小計HDD
director	8	16 GB	100GB	1	8	16 GB	100GB
controller	2	32 GB	40GB	3	6	96 GB	120GB
compute	8	34 GB	60GB	4	32	136 GB	240GB
storage	3	32 GB	640GB	3	9	96 GB	2 TB
合計	-	-	-	-	55	344GB	2.5 TB

上記のスペックのマシンが手に入れば、当面、実験には困らないように思います。

まとめ

ここまでお付き合いいただきましてありがとうございます。結局のところ、やはり、かなり大きなマシンを手元におく必要がありそうという見積りになりました。実際に、こういった計算をしました。これだと、一台で賄うというのは、Ivy Bridge 世代のXeon だと厳しい様に思います。

ということで、次回の記事では、幾らか妥協していく（というよりは、ケチっていく）作戦ついて触れつつ、実際に購入したマシンのスペックの紹介と、そのうえに構築した取り敢えずの実験環境 ( RHOCP + RHOSP + RHCS )の紹介をしたいと思います。また、今回は、個々の製品のコンポーネントであるとか、専門用語、固有名詞についてまったく説明をしていませんので、それらにフォーカスして製品を紹介していくような記事もかけたらなと思います。面白い実験が出来たなら、それについては、赤帽エンジニアブログで紹介していこうと思います。