この記事では、Azure仮想マシンを異なるVMサイズのAzure仮想ソケット（vSocket）に変更するプロセスを説明します。
概要
AzureのvSocket VMを異なるサイズに変更する必要がある様々な状況があります。 リサイズプロセスはAzureテナントで管理され、VMのリサイズはvSocketまたはサイト設定に影響を与えません。 Cato管理アプリケーションまたはソケットWebUIで変更を行う必要はありません。
Azure vSocketのバージョンと構成に応じて、サイトにはダウンタイムが発生することがあります。
ライセンスの制限
新しいデプロイメントのデフォルトVMはStandard_D8ls_v5です。 現在の環境がこのVMをサポートしていない場合は、Azureの管理者に連絡してください。
ステップ1 - vCPUコアのクォータを確認する
vSocket VMのサイズを変更する前に、指定された地域で割り当てられたクォータがvCPUコア数の増加を許可していることを確認することが重要です。 Azureは地域ごとに許可されるVM vCPUの最大数に対してクォータを設定しています。 VMのサイズを調整する際に、新しいVMのサイズがより多くのvCPUを持つ場合は、その地域のvCPUクォータを超えないことを確認する必要があります。 例として、Azure HAサイトには2台のStandard_D2s_v4 vSocket VMがあり、それぞれが2つのvCPUを使用しており、それを8つのvCPUを使用するStandard_D8ls_v5 VMにリサイズしています。 リサイズには追加で12個のvCPU（各vSocketにつき6個）が必要で、12個のvCPUを追加してもAzure vCPUクォータを超えないことを確認する必要があります。
必要に応じて、関連する地域のvCPUクォータを増加させるためMicrosoftにリクエストを提出してください。 vCPUクォータが超過すると、VMは新しいサイズにデプロイされません。
詳細情報は、関連するMicrosoftのドキュメントを参照してください: クォータの表示 と vCPUクォータの確認。
ステップ2 - vSocket VMを異なるサイズに変更する
このセクションでは、冗長化サイトや単一のvSocketを持つサイトのvSocket VMのリサイズについて説明します。
冗長化サイト（v19以上）のvSocket VMの変更
v19以上のvSocketバージョンを実行しているHAサイトの場合、仮想マシンの概観ページからVMが<強い>可用性セットにデプロイされているかどうか確認してください。 以下に従ってください：
この手順中にHAのフェイルオーバーが機能することを確認することも重要です。 WebUIのネットワークツールセクションに進み、APIテストツールを実行してください。
テストが失敗した場合、Azure HA vSocketのトラブルシューティングで説明されているトラブルシューティング手順に従ってください。
APIテストが成功した場合、次のセクションに記載されている手順を進めてください。
注:
リサイズ操作中に、セカンダリvSocket上のソケットWebUI APIテストツールが次のメッセージを返した場合：
Azure APIテストステート『現在のソケットのNIC設定を取得』が失敗しました！ Azure APIブロックステート『すべてのAZ API解除』
テストがプライマリvSocketで成功した場合、これは誤りなので、この結果を無視して以下のリサイズ手続きを続行してください。
可用性セットなしのHA vSockets
vSocketが<強い>可用性セットにデプロイされていない場合、次の手順に従って各VMを個別にリサイズしてください： 仮想マシンのサイズを変更。 プロセス中にダウンタイムは発生しません。
プライマリvSocketをリサイズする。 vSocketはリサイズプロセスの一環として再起動し、サイトは自動的にセカンダリvSocketにフェイルオーバーします。
リサイズプロセスが完了し、プライマリvSocketが稼働を開始した後、サイトは自動的にプライマリvSocketにフェイルバックします。
セカンダリvSocketをリサイズする。 vSocketはリサイズプロセスの一環として再起動します。
最後に、プライマリVMを電源サイクルして、vSocket用HAが機能していることを確認するためにHAフェイルオーバーをテストしてください。
可用性セットを持つHA vSockets
注:
可用性セットで3つのNICを持つStandard_D2s_v4 VMのリサイズについては、Microsoftに問い合わせてください。 以下のステップで、可用性セットがあるHA vSocketsを正常にリサイズできることを確認しました。
vSocketが<強い>可用性セットにデプロイされている場合、次の手順に従って各VMを個別にリサイズしてください： 仮想マシンのサイズを変更。 プロセス中にいくらかのダウンタイムが発生します。
セカンダリvSocketをリサイズしようとする。 リサイズ操作は、プライマリvSocketがNIC制限を超えたというエラー報告で失敗します。
プライマリvSocketをリサイズすると成功します。 これにより、両方のvSocketsが再起動し、トンネルが再接続されます。
両方のvSocketsがオンラインになりますが、リサイズのためLANトラフィックルートが失敗する可能性があります。 プライマリvSocketにフローティングIPを割り当てるAPIコールが初めに失敗することがあります。
ルーティングの問題がある場合、プライマリvSocketを通じて接続を復元するためにセカンダリvSocketをシャットダウンしてください。
セカンダリvSocketを開始する。 vSocketが起動している間、トラフィックは約2分間通信を停止することがあります。
v19より低いHAサイトのvSocket VMの変更
v19以下のvSocketバージョンを実行しているHAサイトの場合、プライマリ（アクティブ）とセカンダリ（待機中）のvSocket用に新しいVMを展開することをお勧めします。 Azure vSocketsの登録解除と再展開を参照してください。 vSocketはv19.xの新しいVMサイズに展開されます。
同じバージョンを保持する必要がある場合は、サポートに連絡してサイトを手動で再作成してください。
サイト用の単一vSocket VMのリサイズ（v19以上）
単一のAzure vSocket v19.x以上のサイトの場合、vSocketはリサイズプロセスの一環として再起動し、サイトにはいくらかのダウンタイムがあります。
VMのリサイズ方法についての詳細はMicrosoftのドキュメントを参照してください： 仮想マシンのサイズを変更。
v19より低い単一vSocketサイトのvSocket VMの変更
v19以下の単一vSocketサイトの場合は、Azure Marketplaceを使用して新しいVMを展開することをお勧めします。 vSocketはv19.xの新しいVMサイズに展開されます。 MarketplaceからのAzure vSocketsの展開を参照してください。
同じバージョンを保持する必要がある場合は、サポートに連絡してサイトを手動で再作成してください。
ステップ3 - リサイズ済みvSocketの確認
VMのリサイズ後のvSocketが正しく機能していることを確認するには、Cato管理アプリケーションを使用して、vSocketのためにソケットWebUIにログインします。
リサイズ済みのvSocketを確認するためにソケットWebUIにログイン：
ナビゲーションメニューから、<強い>ネットワーク > サイトをクリックし、サイトを選択します。
ナビゲーションメニューから、<強い>サイト設定 > ソケットをクリックします。
ソケットの<強い>アクションメニューから、<強い>ソケットWebUIを選択します。
ブラウザは新しいタブを開き、ソケットWebUIにログインします。
vSocketが正常に機能している場合、ソケットWebUIはモニタタブを表示し、アクティブなリンクには緑の<強い>リンクステータスアイコンがあります。
HA構成の場合、上記の手順をセカンダリvSocketにも繰り返してください。