貸そうか？: 2018

（６）全体で必要なキャッシュ容量　・・・　実際に読み書きに対して10%以上
（７）ActiveなESX台数で割る

（８）最後にStandby相当のESXを１つ追加

◆計算例（実効５TB、３+1ノード構成、FTT=1の場合）

◯Capacity計算
（１）Datastoreとして、実効5TB必要な場合
（２）5 ÷ 0.7 ＝ 7.15TB （FTT[可用性]の要件にかかわらず、必要）
（３）7.15 × 2 ＝ 14.3TB （可用性[FTT]を考慮した全体の物理容量）
（４）14.3 ÷ (4-1) ＝ 4.8TB （ESX１台あたり必要な物理容量）
（５）1.2TBのSASドライブ４本（Capacity要件）

　　→最後に、コンパチが取れているパーツであることを確認
　　→パーツの販売終了などもあるので、最新状況はDistributorに相談を

◯Cache計算
（６）5TB × 10% ＝ 500GB（実効の10%以上、全体で必要な容量）
（７）500GB ÷ 3 ＝ 170GB （ESX１台あたり必要な容量）

　　５番＆７番の結果より、各ESXに搭載するvSANドライブは
　　　「Cache：200GB x1」「Capacity：1200GB x4」が確定　※Boot用は別途

　　→Cache/Capacityドライブ数の組合せが、論理仕様に収まっているかチェック
　　→最後に、コンパチが取れているパーツであることを確認
　　→パーツの販売終了などもあるので、最新状況はDistributorに相談を
　　　SSDは世代交代が激しいので注意！　後継のパーツ案内してくれるDistiが親切

（８）Standby相当のESXをもう１台プラス　※縮退時のデータコピーを考えて
以上

2018年8月26日日曜日

LAS（マッカラン国際空港）からの移動は、Uberで!!

#VMworld 真っ盛りなので、移動に便利なHackをいくつかお届けしたいと思います。

空港→ホテルの移動は、Uberをおすすめします。

ホテル等からの移動は、TAXIとUberでエリアの棲み分けなどがありますが・・・
空港でのUberは "Ride Shre"システムとしてきちんと完成されているのです。

＝＝＝＝おおまかな流れ＝＝＝＝

国内編：
（１）日本にいるうちに、Uberアプリをインストール
（２）連絡先とカード決済情報を設定しておく
（３）予めホテルがわかっていれば、行き先を保存しておく

現地編：
（４）乗車人数・荷物の規模・Uber乗り場を把握
（５）アプリでUberを手配（ドライバーが確定すると、車種・ナンバーが通知されます）
（６）合流地点で待ち合わせ（ドライバーとはTextチャットでやり取り）
（７）ドライバーと軽く挨拶。自分の名前を伝えていざ乗車。目的地はUberで説明済み
（８）目的地に到着しても支払い不要（Uberと連携したカードで引き落とされます）

その後：
（９）メールで金額の引き落とし結果が届きます。
（１０）ドライバーの評価（★５つがMax評価）をお忘れなく!!

＝＝＝＝いざ、実践 !! ＝＝＝＝

2018年6月14日木曜日

1ノードSDDC

こんな記事が海外に出ていました。
https://blogs.vmware.com/virtualblocks/2018/06/07/single-host-vsan/

要約すると
　・VMC on AWS (VMware Cloud on AWS)で、30日トライアル期間が用意された
　・可用性はない（FTT=0）
　・Webコンソールから簡単に本番構成（４ノードSDDC）に移行できる
　・トライアル期間終了までに本番移行しないと、自動で消去される
とのこと

さすが、SPBM（Storage Policy-Based Management）ならではの運用ですね。

ポイント
　・2N+1構成ルールから考えれば、FTT=0なら (2x0)+1 = 1 なので当然正しい動作
　・VMC on AWSらしく、ワンクリックで物理ノードをクラスタに自動追加
　・その他構成はSDDCなので全自動
　・ノード拡張後は、SPBMで可用性を簡単にUPできる

SPBMは、LUNベースの可用性管理から、VM単位の可用性管理が特徴で
VMのコストとSLAのバランスを柔軟にコントロールすることができます。

さらに、デフォルトでポリシーを定義しておくことで、
VM作成時にストレージの可用性（どのデータストアに配置するか？）を意識することなく、楽々運用ができます。