試験 Azure 70-533 を1週間で取得 Day2

今日もAzure 70-533 インフラストラクチャソリューションの資格を取得するために頑張って書いていきます、殴り書きです。
※この記事は7月24日に書きました

#[Day2]サイト間接続と仮想マシンと時々Webシステム
##Azureのリソースを見よう
###[すべてのリソース]を見てみる
左メニュから[すべてのリソース]を選択して、作成してきたリソースを眺めてみる
- DHCPで動的に払い出されているDIPはリソースではない
- Public IPアドレスについてはリソース管理される（設定値）
- Azure IaaSの可用性セットは論理的な設定値がリソースとして表現される

###リソースグループ

- ASMではただの分類だったが、ARMでは高度な機能を持つようになった
リソースのライフサイクル（更新や削除など管理したい業務が同じ）を合わせて設計、デザインパターンを持つとよい
- [すべてのリソース]を見て分かる通り大量のリソースを更新したり削除したりしたいとき、1つ1つ消してなんかいられない
- さらに1つVMを消すのに仮想ネットワークを消す、その前にIP-Addrを消し、ディスクアカウントを消す、その前にVMを消すのか？などなど依存関係がASMでは存在していた
- ARMではリソースグループを消すだけで1発で同じリソースグループに所属しているリソースは削除される



- [ ] リソースグループはAzure ARMモデルにおいてリソースを作成する際に必須のコンポーネント
- [ ] リソースグループを削除すると原則リソースグループ内のすべてのリソースが削除される
- [ ] 例外はあり、仮想ネットワークと仮想マシンのリソースグループが別の場合(通常は別）、仮想マシンがある状態で仮想ネットワークは削除できない

##リソースグループのデザインパターン
つまり1つの再利用したい仮想ネットワークVNet上で動作するWeb/WebApp/DBと3つの仮想マシンがあった場合、Web/WebAppの2つのサーバはWindows BaseのIIS, CSS/HTML5, JavaRunTimeなどで動作しライフサイクルを同じで管理したいという思想な場合、同一のリソースグループで管理したほうが望ましいとなる

でも実際の現場ではサーバの役割ごとにリソースグループを作ったほうが良いかもしれない
この子はAD、この子はFILEserver、SMTPなどなど、役割ごとにリソースグループを作る
諸説あると思うので色んな人のデザインパターンをお聞きしたいです

##VNet間接続(Day1の続き)
###ローカルネットワークゲートウェイの作成
1. HQ側で対抗のBR向けのゲートウェイを設定する
2. 左側のメニュから[リソースの作成]をクリック
3. [ネットワーキング]から[ローカルネットワークゲートウェイ]を選択
4. 各パラメータを設定していく
5. 名前, IP-Addr（ここは対抗のBR側のゲートウェイのPublic IP-Addrを入力)
6. アドレス空間は対抗のサイトのもの、つまりここではBR側を入力する
7. [すべてのリソース]から各サイトのローカルネットワークゲートウェイを確認する

##VNetサイト間VPNの接続設定
実際にサイト間のVPN接続の設定を下記の手順で設定していきます
1. [すべてのリソース]からHQ側の[ローカルネットワークGW:br-localnet]を選択
2. [接続]を選択
3. [追加]のプラスアイコンをクリック
4. 各種パラメータを入力していく
5. 名前は接続名を分かりやすく
6. 仮想ネットワークは自身の仮想ネットワークVNet
7. ローカルネットワークゲートウェイは対抗を入力
8. 共有キーはVPNの任意の文字列を対抗同士で合わせて入力
9. 最後に[OK]を押してデプロイ

##サイト間VPN接続(VNet間)のステータスチェック
すべてのリソースから接続時に作成したリソースを選び、[データ入力]項目に値が乗っているかチェックする⇔接続時点でkeepalive的な通信があるのですでにトラフィックは流れる
（私の場合は512Byte流れていた)

#仮想マシンの実装
##仮想マシンとは

- exportするとテンプレートはJSONファイルが吐き出されるので、それをインポートする際にARMテンプレートは便利
- Azure CLIやAzurePowerShellのコマンドレットなどを利用して仮想マシンを作成する
- AzureCloudServicesとはPaaS向けのコンポーネントであり、初期（IaaSv1/クラッシック）のものが必要だったが、IaaSv2からは必要なくなった

##仮想マシンへの接続
昨日、作成した仮想マシンにRDP(3389)よりPublic IP-Addr経由でアクセスする手順
1. Window系からなら[Windowsを検索]
2. mstsc /v:XXX.XXX.XXX.XXX /f を入力 (GUIからRDP選んでもいいよ)
3. 上記のIP-AddrはAzure Portalから対象の仮想マシンのPublic IP-Addrを確認しておく
4. クレデンシャル（資格情報）を入力してRDP完了

##イメージによる仮想マシンの作成
イメージを使用してAzure仮想マシンを作成できます
オンプレのVMからイメージを取得する、もしくはMarketplaceから既存のイメージを使用できます

- Windows Server
- Linuxのディストリビューション
- データベースサーバ
- アプリケーションサーバ

sysprepによるコンピュータ固有情報を削除、一般化してAzure仮想マシンを再利用可

###Remote Desk TopのAzure上のメモ知識（楽に検証するために）
1. Azure Portalの[Virtual Machines]から該当の仮想マシン選ぶ
2. 概要から[接続]というプラグのようなアイコンをクリックしRDPふぁいるのダウンロードを選択
3. のRDPファイルのダウンロードを行ったら、作業しやすいデスクトップなんかに配置して下記を右クリックの編集から設定しておく

- 資格情報
- Cドライブとのデータやり取り
- RDP画面のサイズを1024x768を設定（接続時に画面がわかりやすい）

##Azure仮想マシンのワークロード識別
- Azure仮想マシンに適したワークロード
    - 高可用性サービスワークロード
    - 定期的な成長が予測できない、または急上昇するワークロード
    - 安定したワークロード
- Azure仮想マシンに適さないワークロード
    - 低ボリュームで成長が限られたワークロード
    - 規制された環境のワークロード
        - 軍や政府
        - 製薬会社などの研究機関などはオンプレミスで
- 仮想マシンの代わりにPaaSの使用を検討
- Azure仮想マシンのソフトウェアサポート
    - Windows serverの役割
    - その他のサーバ製品(SQL,Sharepoint, System Center)
    - Linuxディストリビューション

##Windows過疎マシンの未サポートの役割（2018/7/24時点)
下記が未サポートの役割と機能
- DHCPサーバ
- Remote Access (DirectAccess)
- Rights Management
- Windows展開サービス
- マルチパスI/O
- ピア名解決プロトコル
- などなど

###新規構築した仮想マシン(Windows server 2016の場合)を日本語に設定
1. [Windowsボタン]上で右クリックし[Control Panel]を選択
2. [Clock, Language, and Region]を選択
3. [Add a language]より対象言語を選ぶ[日本語]
4. [Move up]を押して日本語を優先度高く設定
5. [Options]から[Download and install language pack]を選んでインストール
6. 完了したらサーバを再起動してサーバマネージャ上で日本語になっているのを確認

##仮想マシン(windows)の開発環境構築（備忘）
下記をwindows server上に構築
- 言語パックのインストール
- IISのインストール
- VisualStudio Communityのインストール


## Azureへのワークロードの移行
Azureに仮想マシンをアップロードする際の留意点
- .VHDファイルはHyper-V仮想マシンのものであること
- .VHDXファイルはサポートされない
- sysprep.exeによりオンプレミスの仮想マシンを一般化する必要がある
- .VHDファイルは固定サイズの仮想ディスクであること
128GBの固定サイズにしてアップロードする必要がある

Azureへの移行についてはこちらの方のサイトがわかりやすかったです
<https://www.slideshare.net/wintechq/hypervazurev2c>

## Azureコンテナの使用の評価
###そもそもコンテナについて
Hyper-Vなどの仮想化サーバは使わずにコンテナエンジンをサポートするOS(Win2016/Linux)をインストールする、そのOS上でコンテナを作成する

###コンテナの特徴

- 下記の3層からなり、親OSのリソースを隔離してあたかも複数のサーバが動作しているようにみせる機能をもつ
    - アプリケーション
    - ランタイム（アプリの開発環境) JavaRunTime,.Netflamework等
    - ミドルウェア

- ハイパーバイザと異なり親OSがそのままリソース分割されているイメージ、他のOSは動作できない
- コンテナはアプリケーションの開発/実行環境のみ提供し、ミドルウェア、ランタイム、アプリケーションで構成され、ハイパーバイザに比べサイズが小さく扱いやすい

メリットはサイズが小さいのでシステムの入れ替えがやりやすい、つまりライフサイクルが早いアプリケーションや機能のアップデート頻度が高いサービスと相性が良い

またアプリケーション開発者にとって本番環境と検証/開発環境を一致させやすく管理しやすいので動作の確実性を担保することができる

###Azureコンテナ
Azureもwindows server2016よりコンテナを提供している(2018/7/24)
詳細はこちらを参照 <https://azure.microsoft.com/ja-jp/overview/containers/>

##仮想マシンの管理
###仮想マシンの可用性（可用性セット)

- 可用性セットは2つ以上の仮想マシンを論理的にグループ化したもの
- IaaSの仮想マシン作成時に参加させる必要がある
- 作成後に可用性セットに参加させることはできないので事前の計画が必要
- 可用性セットのSLAは99.95%
- 障害ドメインと更新ドメインという考え方があり、ドメインを分けて可用性を高める
- 障害ドメインはサーバラック、同一の障害ドメインはラックが同じという意味
- 更新ドメインは仮想化ホスト（物理サーバ）、同一の更新ドメインは同じ仮想化ホスト上で動作しているという意味
- 障害ドメイン top of rack(SW)やネットワークケーブル周り、電源周りを共有しているので、このあたりに障害やメンテがある場合は違うラックにライブマイグレーションされ、SLAをMS社は担保しようとする
- 障害ドメインはデフォルトでは[2]、更新ドメインは[5]、前者は着地する先のラック数、後者は仮想化ホスト数を意味する
- 最大値では障害ドメインは3、更新ドメインは20まで設定ができる


##Azure Load Balancerの概要
Azure LBはソースIPアドレス、ソースポート、接続先IP-Addr、接続先ポート、IPプロトコル番号からなる5つのハッシュを使って使用可能なサーバにフローをマップする
負荷分散を主にLoad Balancerを利用する
SSLアクセラレータ機能+負荷分散を行い場合はapplication gatewayを使う
※AWSのLBは上記が同一のリソースデバイスになっているのが比較の特徴でよくある

###Azure Load Balancerの作成と設定
1. [リソースの作成]から[ネットワーキング]を選び[Load Balancer]を選択
2. 各種設定項目を入れていく
種類はパブリック（インターネット受信トラフィックを分散）
SKUは安価なBasicを選択
3. Public IP-Addrやリソースグループを新規で作成しデプロイ
4. デプロイ完了したら[すべてのリソース]から作成したロードバランサを選択
5. [バックエンドプール]を設定　※LBの裏でうごく仮想マシン群を選ぶ
6. 関連付けは可用性セットを使っているので、そちらを選択
7. ターゲットネットワークIP構成の追加より該当のVMとDIPを選んでOKをクリック
8. [正常性プローブ]を選び追加をクリック
9. リソース設定の名前を任意で入れたら、プロトコルはTCPは80を入れる（デフォルト）
10. 間隔やしきい値はそのままでOKを選択
11. [負荷分散規則]を選択
12. 名前つけて、デフォルト設定でそのままOK
13. [受信NAT規則]を選択
14. フロントエンドIPアドレスやサービス、ポート、ターゲット仮想マシンを選択
15. LBのフロントエンドIPのリソースからFQDNを設定していく
16. [すべてのリソース]からLBのPIPのリソースを選択して[構成]を選択
17. DNS名ラベルを任意で記載し、右下のドメインもメモっておく
18. あとはブラウザからインターネット越しにhttp://XXXでアクセスしてみる
19. IISのアクセスログを見ながらチェック(C:/inetpub/logs/LogsFIles/)

###IISのインストールメモ
Azure Load Balancerで負荷分散を試すために仮想マシンでIISを2台立てる
1. サーバマネージャから[管理]を選択
2. [役割と機能の追加]より[Web server(IIS)]を選択
3. 次へをポンポンと押していって[インストール]をクリック
4. インストールが完了したらIEなどのブラウザからhttp://localhostへアクセス
5. IIS(Internet Information Services)のTOP画面が見れたらOK

###SQL Serverのインストールメモ
1. googleからSQL server Express 2017のページへ
2. インストーラをダウンロードして[カスタム]を選びながらインストールしていく
3. インスタンス名はMSSQLSERVERに変更すること（必須）
4. [SQL Serverの新規スタンドアロンインストールを実行するか、xx]を選択
5. デフォルトで[次へ]をポチポチしていく
6. インスタンスの構成で[既定のインスタンス]を選ぶこと⇔MSSQLSERVERがID
7. 認証モードは[混合モード]を選択し、パスワードを入力
8. [承諾]と[次へ]をポチポチしてインストールが開始される


##Azure 仮想マシン　ディスクの概要

Azureは次の３種類のディスクをサポートする

- オペレーティングシステムディスク
    - ラベルはCドライブで仮想マシンにはSATAドライブで認識される
- 一時ディスク
    - ラベルはDドライブで仮想マシンごとに１つ
- データディスク
    - サイズは使用されるVMサイズにより異なる
    - 最大容量は4TB(昔は1TBだったらしい) ※2018/7/24時点

###ディスクの細かな特徴
- Azureの仮想マシンのディスクは容量固定
    - 例：1TBなら1TB分を最初から消費する
- ディスクにはHDDとSSDが選択できるサイズがある
    - BシリーズはSSD限定
- HDDは格納されたデータサイズで課金される仕組みとなっている
- SSDはディスクサイズで課金されるため1TB中消費がゼロでも1TB分が課金される
- 仮想マシンを作ったときにD:¥は一時ディスク(temporary disk)となり消える可能性がある※DATALOSS_WARNING_READMEファイルが勝手にD:¥に作られる
- D:¥は一時データを保存する専用のドライブ 性能面に寄与するための特殊なキャッシュで使われるドライブ 明示的に格納したデータは削除される可能性がある
- D:¥に格納されたデータはポータルから停止（割当の停止）すると削除される
- D:¥のドライブレターは変更できないので追加のデータディスクはE以降となる

###ストレージアカウントの課金
仮想マシンのディスクの構成を計画する際はストレージの使用に関わる次の4つの基準に従いながら請求金額が計算されるので注意

- ディスク領域の合計容量
- レプリケーショントポロジ
- トランザクション量
- データ送信
    - ストレージの課金は上り（アップロード）は無料
    - ストレージにアクセスしてダウンロードする場合は課金される
        - 例：サイト間接続で米国の東部と西部間でデータを授受すると片方から1TBのデータを送信した場合、課金される

まずはDay2はここまで。明日Day3はAzure Appsをやります。

※この記事は7月24日に書きました