Qrunchからお引越しした記事です : created_at: 2019-08-31 10:56:03 +0900

仮想マシン周りは概ね理解しているので、微妙に知識が足りないところだけ補足学習。

0. スキルの評価対応

仮想マシン （VM） のデプロイと管理

1. 仮想マシンの複数展開

1.1 イメージからの作成

イメージを作成するVMはSysprepを使う。
Linuxの場合waagent -deprovision+userでAzureのエージェントを初期化する。

1.2 ARMテンプレートでの展開

CopyオブジェクトやCopyIndexを利用するとよい。
複数の名前や値を生成できる。
例）次の場合、storage0、storage1、storage2の名前が生成される。
　名前
　"name": "[concat('storage', copyIndex())]",
　Copyオブジェクト
　　 "copy": { "name": "storagecopy", "count": 3 } 　
なお、ARMテンプレートの編集はVisual Studioで実施するとやりやすいらしい。

1.3 仮想マシンスケールセット

可用性セットとは別物。
この機能でVMを作成すると

すべての VM インスタンスが同一のベース OS イメージと構成から作成されます。
　というようにVMとして同一内容を保持した状態で自動スケールが実行できる。

基本、LoadBalancerを通してアクセスすることになる。
スケール方法は３つ
①手動
②スケジュール指定（スケールアウトするVM数も指定可能）
③メトリクス（CPU利用率など）の数値で自動スケールアウト

「え、すごい便利じゃん」と思ったが、下記情報あり。

※仮想マシン内にデータの保存はできますが、スケールインされるため、大切なデータは保存しない方が良いです。また、仮想マシン間でデータを共有する事もありません。

参考：https://www.cloudou.net/virtual-machine-scale-sets/vmss001/

…使えるケースが限られますね。（ログファイルとか消失するじゃん）
保存が必要なファイル（ログファイルなど）は別場所保管に設計すればいけるか。

2. 仮想マシン移行（オンプレミス to Azure）

2.1 Azure Site Rocovery

・実施前にDeploy Planner Toolを実行して情報収集をした方が良い。
　⇒ASR利用にあたるオンプレミスの情報がEXCELで出力される。
　　移行に必要な帯域幅や時間の情報を把握できる。
・構成サーバ、および移行元ホストはそれぞれHTTPSでAzureと通信し移行する。
　⇒443ポートで行うが、データ転送は9443ポートで行う。注意。
・Azure側ではリカバリーサービスコンテナ、ストレージアカウントが必要。

2.1.1 From Hyper-V

Hyper-VがSystem Center VMMで管理されている場合VMMが必要なケースあり。
移行元ホストにはAgentを導入する。
　

2.1.2 From Physical Server　

・構成サーバが必要。構成サーバがレプリケーション調整などを実施。
　⇒ちなみに構成サーバはSQL ServerでなくMySQLで稼動するらしい。
　⇒データ転送ポートを9443から変更することもできる模様。
・レプリケーション対象のサーバにはモビリティサービスエージェントを導入する。
・ASR自体はフェールバックも考慮したサービスだが、P2C移行になると
　フェールバックは難しい。物理サーバからの移行についてはP⇒Cへの一方向で考えたほうがよい。
　⇒ドキュメントを参照するかぎりできなくはないと思うが、あまり推奨しないということだろう。

2.1.3 From VMware

構成サーバーが必要。⇒OVFファイルがあるため、VMware上にデプロイするとよい。

2.2 Azure Migrate

・オンプレミスで稼働しているVMware上の仮想マシンを、Azureに移行した場合の
　「構成」や「費用」の確認ができるサービス（らしい）
・あくまでレポート情報を作成するだけであり、移行はASRで行う。
・VMware環境の情報収集に利用できる。（現在はHyper-Vも利用できる？）
　OVAファイル経由で収集用VMをデプロイし、収集結果をAzureへ送信し、その結果をレポートにまとめる、という流れか。
　（参考）https://www.cloudou.net/azure-migrate/mig001/

2.3 Data Migration Assistant

SQL Serverの移行などに利用。割愛。（おそらくAZ-103の範囲外）

2.4 ASRを利用しない移行

長期間のダウンタイムが許されるのであれば、下記方法もある。
①Hypre-VのVHDファイルをアップロードして使う
②Azure DataBoxでVHDファイルを移送して使う

3. カスタムスクリプト拡張、PowerShell DSC

Azureのカスタムスクリプト拡張機能と、DSCを使って、
デプロイした直後のVM 構成（エージェントやアプリ導入）を整理しましょう、という話のはず…（自信ない）

3.1 カスタムスクリプト拡張

・仮想マシンを作成したタイミングで、スクリプトを流せる機能。
・Win2008R2以上で利用可能。

3.2 PowerShell DSC拡張

・（Azureは直接関係ない）
・構成管理用の拡張機能。
・役割の有効化や環境変数の設定、ソフトウェアインストールなど構成に関することが色々できる。
・参考サイト：https://www.slideshare.net/kazukitakai/dsc-88799528

3.3 組み合わせてできること

・VMを作成した直後にウィルスソフトウェアインストール
・VM作成後のエージェント導入状態を同じくなるように管理
・その他いろいろ

4. 所感

・カスタムスクリプト拡張、PowerShell DSC あたりがPlurasightになかったので独学。
　⇒内容および範囲があっているのかどうか不安。
・ASRは業務で抑えていたのでおさらいレベル。
・スケールセットは可用性セットのことかな、と完全に勘違いをしていたので、把握できてよかった。