VMware製品構成上限の簡単な確認方法
昨今、数多くのVMware製品が提供されています。
見積もりや設計段階で構成上限を確認することは必須な作業ですが、
様々な製品が絡み合いとても複雑で、見誤ると設計に大きな影響を及ぼしかねず骨の折れる作業となっています。
そんな中、構成上限を簡単に確認できるサイトがリリースされていましたのでご紹介します。
VMware Configuration Maximums
例えばHorizon on VMC on AWSの構成上限を確認したい場合は左側の項目にチェックをいれていくだけです。
VMC on AWSとHorizonにチェックを入れると関連するOraganization Maximumsにも自動でチェックが入りました。
左下のview limitをクリックすると結果が表示されます。
PDFに出力でき証跡にもなるのでかなり良いです。
仕様変更で設計時と上限が変わり大きな影響が出ると後々責任論になりかねないので、
はっきりさせる＋自分の身を守るためにも残しておくことを強くお勧めします。
結果を見てみますと組織辺りのホスト上限32ホスト、パブリックIPの上限75
SDDCあたりのVDI数2,000と表示されています。
softLimit部分はサポートに依頼すると上限緩和できるものもあります。
眺めているだけでも知らない上限があったりして新しい発見があるのでお勧めです。
Amazon FSxでバックアップ成功・失敗通知を受け取る方法
今回はAWS上で構築できるファイルサーバ Amazon FSxのバックアップについて記載します。
FSxのバックアップはFSx作成時に設定できるデフォルトの仕組みとカスタムバックアップの2種類があります。
デフォルトの仕組みのほうが設定しやすいのですが、こちらですとバックアップの成功・失敗を通知することができません。
さらにカスタムバックアップですと通知を発報できるだけでなく、デフォルトでは日次取得であったバックアップ頻度をcronによりきめ細かく設定することが可能となります。
CloudFormationテンプレートが用意されており、これをインポートするだけで簡単にカスタムバックアップを設定できます。
仕組みとしては以下となります。
・CloudWatchでイベントをトリガー
・Lambdaで処理
・FSxでバックアップ取得
・SNSで通知
というシンプルな仕組みになっています。
それでは早速設定してみましょう。
まずAWSコンソールの検索窓でCloudFormationを選択します。
CloudFormationの初期画面でスタックの作成を押下します。
「新しいリソースを使用」を選択します。
「テンプレートの準備完了」-「テンプレートファイルのアップロード」を選びます。
テンプレートは以下の公式サイトからDLできます。
https://docs.aws.amazon.com/fsx/latest/WindowsGuide/custom-backup-schedule.html
ダウンロードしたテンプレートを選択してアップロードすればOKです。
任意のスタックの名前を入力し、FSxの管理画面で表示されているFile SYstem IDを入力します。
バックアップのパラメータを入力します。
以下の値では「24Hに1回つまり日次」且つ「UTC0時 日本時間9時」に取得
保持世代数は「2」。Name for Backupsは任意のものでOKです。
Backup NotificationをYESにすると成功時もメール送付されます。
最後に送信したいメールアドレスを入力するだけです。
他の値はデフォルトのままで以下のチェックを入れてスタックの作成を行います。
Amazon SNSのほうにも先ほど入力したメールアドレスのSNSトピックが作成されています。
SNSは承認しないとメール送信されませんので、まだ保留中になっています。
※メアドは黒塗りにしています。
指定したメールアドレスあてにconfirmのメールがきているかと思いますので、
confirm subscriptionをクリックします。
成功すると以下の画面に遷移します。
先ほどは保留中であったものが確認済になります。
これでメール受信されるようになります。
翌日の朝にメールを確認すると成功メールが届いていました。
ちなみに長いURLをクリックするとunscribeされ、再承認しないとメール受信されなくなりますので注意が必要です。
FSxのBackup管理画面でも朝9時にバックアップが取得されていました。
以上がカスタムバックアップ作成からの成功・失敗通知の設定方法でした。
CloudFormationテンプレートが提供されているおかげで簡単に設定できますのでお勧めです。
クラウド移行のお供 VMware HCXの概要紹介とBest Practice
今回は主にオンプレミスからクラウドへの移行及びL2延伸で利用するVMware HCXの概要について記載します。
クラウドへの移行方法は様々な方式があります。
個人的にはAWS Lambdaなどクラウドの新しいテクノロジーを活用するために新規にシステムを作り直すことをお勧めしていますが、移行する際に止められないシステムだったりIPaddressを変更できないシステムは多いかと思います。
そんなシステム向けにお勧めしたい移行方式がVMware HCXを活用した移行方式です。
HCXを利用するとオンプレミスの仮想マシンをオンラインでクラウド上に移行できたり、逆にクラウドからオンプレミスへオンラインで戻すこともできちゃいます。
まずはHCXの各コンポーネントのご紹介です。
・HCX SaaS endpoint
これはHCXライセンスのアクティベーションする際に利用するSaaSサービスです。
他にはバージョンアップ・SWのダウンロードする際に利用します。
・HCX Manager
各HCXコンポーネントの管理を実施でき、APIサービスのEndpointとして機能します
・HCX WAN interconnect Vrtua Appliance(HCX-IX)
移行機能を提供するアプライアンスです。
HCX Manager経由で簡単にデプロイすることができます。
・HCX Network Extension Virtual appliance(HCX-NE)
こちらはL2延伸機能を持つアプライアンスです。L2延伸しない場合は不要です
延伸するNWが8個以上の場合はアプライアンスを多くデプロイする必要がありますので注意が必要です。
こちらもHCX Manager経由でデプロイする形となります。
・HCX WAN Optimization Virtual Appliance(HCX-WO)
移行時のトラフィックを重複排除・圧縮する機能を持つアプライアンスです。
またまたこちらもHCX Managerからデプロイする形となります。
上記全て、クラウド・オンプレ側両方にデプロイして構成する形となります。
HCXを利用した移行には3種類あります。
・vMotion 無停止で移行可能
・Bulk Migration 切り替え時の電源オフ・オンのみ停止
・Cold Migration 全停止
当然、無停止の場合は満たすべき要件が多く、下にいくにしたがって要件は緩くなります。
バージョンアップを経て条件が変わる場合が多いので最新の要件は以下をご参照ください。
また注意点ですがクラウド側はCPU世代をコントロールするEVC機能がオフになっています。
そのためオンプレ側がBroadwellであればオンラインでオンプレに戻せますがそれ以外の場合はオンラインでは戻せず停止が発生します。
オンプレ同士のvMotion時もそうですが、EVCが無効では異なるCPU世代のHW間でvMotionできないのと同じです。
ここからは各種のベストプラクティスと留意点について説明します。
★HCXを構成する上でオンプレミスとクラウド間は冗長することがベストプラクティスです。
また、回線のプロバイダも分けることが推奨されています。
複数のUpliknkパスがある場合はHCX側で最適なパスを計算して利用してくれます。
★各HCXコンポーネントのDRSレベルはPartially Automatedが推奨値です。
★各HCXコンポーネントのHA再起動優先度をL2延伸ネットワーク上のVMより高くして起動を早くする設定が推奨値です。
★HCX Enterprise Managerはプロキシ経由の通信をサポートしますがそれ以外は未サポートです
★プロキシを設定する場合は内部通信については除外設定を入れましょう
★認証にはBasic認証のみサポートしているためKerberos/NTLMはサポートしていません
★オンプレ側DNSで名前解決できるようにしましょう。特にクラウド側vCenterのドメインやHCX SaaS Endpointは忘れがちなので注意
★Updateが頻繁に実施されているのでHCXのリリースノートは定期的に確認しましょう
https://docs.vmware.com/en/VMware-HCX/services/rn/VMware-HCX-Release-Notes.html
今回はVMware HCXについて記載しました。
オンプレミスとクラウドでVMware基盤を利用しているからこそ実現できる移行方式は強力なソリューションです
自分もその一人ですが数年前に初めてvMotionをして感動した方も多いのではないでしょうか
今度はオンプレからクラウドへのvMotionを是非、体感してみてください
