Azure アイデンティティおよびガバナンスの管理
Azure ADユーザがAzure Kubernetes Service (AKS) にアクセスできるようにするには、対象のドメインにOAuth2.0のエンドポイントを設定する必要がある
SecurityグループとMicrosoft 365グループ
Securityグループは従来のADにおけるセキュリティポリシーのグループと考えて良い。Microsoft 365グループはかなり特殊な存在。
有効期限付きのグループを作れるのはMicrosoft 365グループだけ
社外の人をADに招待する場合、「external collaboration」を設定
User Access Administrator role
他のユーザに対してReaderロールを割り当てられるような準管理者的なユーザを作りたい。（特定のリソースに対して。どんなロールを付与する必要）
Logic Apps Contributorのロールを持つアカウントはLogic Apps （ロジックアプリというリソース）を追加、編集できる。
IT Service Management Connector (ITSMC)
オンプレのマシンを Microsoft System Center Service Manager (以下 Service Manager)で監視しており、Azure VM で発生したアラートを Service Manager に転送したいときに使用。
Managed Identity settings
リソースを動的に生成するVMを作りたい場合、対象のVMのManaged Identity settingsを設定する。
Management Groupに対して行えるアクションがADロールによって異なる。Ownerロールはもちろんなんでもできる。ポリシーをアサインできるのは Resource Policy Contributor と User Access Administrator のみ。さらにほかのユーザに対してアクセス権を与えられるのは User Access Administrator のみ。 User Access Administrator 強い。でも User Access Administrator は Management Groupを作ったり削除することはできない。普通の Contributor ロールならManagement Groupを作ったり削除することができる。
Delete Lock をかけられる対象は VM などのリソースや、リソースグループ。さらにサブスクリプションにもロックをかけられる。が、 Management Group にはかけることができない。
タグをつけられる対象も上と同じ。
ストレージの作成と管理
Azure Import/Export service
Block blobs, File shares, Page blobsタイプ（この３つの区別をAccount kindと呼ぶ）のストレージアカウントを作りたい場合は、ストレージアカウントを作る時にPerformanceをStandardからPremiumに変更して作成する必要がある。
Azure Import/Export serviceはAzure Blob storage と Azure File storageだけImportできる。
Azure Import/Export serviceはAzure Blob storage だけExportできる。なので、TableやQueueタイプはImportもExportもできない。
Storage Accountにアプリケーションが時間制限付きでアクセスできるようにするにはSAS（shared Access Signature)を使う必要がある
General Purpose v1 (GPv1) アカウントはティア（Tie）をサポートしない。つまり、Hot, Cool, archiveの区別がない。GPv2はある。
ティア（Tie）をサポートしているのはGPv2と BlobStorage のみ。
GPv1とGPv2はGeneral Purposeと言うだけあって、色んな種類のデータを格納できる。色んな種類とは、Blob、File、キュー、テーブルの4つ。一方、Blob StorageタイプのStorage AccountではBlobしか格納できない。
Azure にデータを送りたい時、送り先として使えるのはどれか？
- Azure File Storage
- Azure Blob Storage
Locally Redundant Storage (LRS) では 1ゾーンの中の異なるDCに3つのレプリケーションが同期的に作られる。
- AzcopyではBlobとFileをサポート
| ストレージ | 認証方式 |
|---|---|
| Blob | Azure AD, SAS |
| File | SAS |
AzCopy でコピーできるのは blob と file だけ。table と queue はサポートされていない。
AzCopy を使うとき、認証方法は基本的に SAS (Shared Access Signature)しか使えない。ただし、Blobをコピーする時は Azure AD でも認証できる。
Azure 計算資源の展開と管理
App Serviceと App Service Plan
App Serviceは[Web Apps]などのアプリケーション群の総称
App Service を作成する場合、必ず App Service Plan も一緒に作らないといけない。 App Service Plan というのは App Service が実行される環境（VM）のこと。
App Service を別のリソースグループに移行するには注意が必要。結論を言うと、App Service を別のリソースグループに移行したとしても、App Service Plan は元のRGに居残っている。
App Service がデプロイされる環境を App Service Plan と呼ぶが、 App Service Plan は複数作ることができる。 App Service Plan が複数あっても必ずひとつのある webspace に配置される。webspace はリージョンとリソースグループの組み合わせで一意に決まる。なので、ある App Service Plan がある webspace にデプロイされると、次に同じリージョンの同じリソースグループに作った別の App Service Plan は最初に使われた webspace と同じ環境に作成される。App Service は同一 webspace 内の別の App Service Plan に移行できるが、別の webspace 内にある App Service Plan には移行できない。
上の説明で行くと App Service は別のリージョンに移動できない（webspace はリージョンとリソースグループによって一意に定まり、 App Service は別の wabspace に移動できないため）。でも移行先のリージョンで App Service Plan を作り、そこに移行したい App Service の複製を作れば行ける。
デプロイスロットを追加すると、ステージング環境を用意できる。これによってシームレスな本番適用ができて、失敗した時はすぐに戻せる。
デプロイスロットを使いたい場合、App Service Plan をスケールアウトする必要がある。
Web App に CNAME や A レコードを設定することで、カスタムドメインを割り当てることができる。
「Availability Set (可用性セット)」を設定することで、VM の可用性をコントロールすることができる。
Azure File Sync
Cloud Endpoint はひとつの Sync group につきひとつ。一方、 Server Endpoint は複数あっても良い。一つのサーバ内の複数フォルダでも良い。でもクラウド側は必ずひとつ。
まず、Azure Filesとは？
- フルマネージドのファイル共有サービス
- コンテナを永続的に置くところとして使われる
Azure File Sync agent をインストールする時、Storage Sync Service のリソース名を登録する必要がある。なので、Agent をインストールする前に Sync Service を作っておく必要がある。
Recovery Service Vault（コンテナ）
データ保護と災害復旧を目的とした「Azure Backup」と「Azure Site Recovery」の2つのサービスがあり、これらのサービスはどちらも「Recovery Servicesコンテナ(Recovery Services Vault)」サービスが提供します。
リカバリサービスコンテナーを使用すると、IaaS VM (Linux または Windows) や Azure SQL Database などのさまざまな Azure サービスのバックアップ データを保持できる。
Azure Backup Report を利用するには Log Analytics workspaces を作成する必要がある。
workspaces を作成する際、Subscription を指定する必要がある。しかし、workspace と コンテナ（ Recovery Service Vault のこと）のSubcription は同じでなくても良い。
同様に workspace と コンテナ のリージョンは同じでなくても良い。なので、 workspace に制限は少ない、と覚えておく。一方で、 コンテナと Storage Account は同一リージョンでなければならない。
Recovery Service Vault で VM をバックアップする場合、一つのVMに対して複数の Vault (バックアップ先) を指定することはできない。
Vault を変更する場合（つまり、バックアップ先を変更する場合）、先に既存のバックアップ設定を停止しなければならない。
Recovery Service vault を削除する場合、最初に「バックアップを停止する」必要がある。次に、バックアップされたデータを削除する必要がある。
Recovery Service Vault では vault と同じリージョンにあるリソースしかバックアップできない。
ASP.NET Core apps は Windows でも Linux でもインストールできる。
.NET Core appsもWindows・Linux・macOS でもインストールできる。
Azure Web Apps は 同一リージョンにある App Service plans にしかデプロイできない。
VM のスケールアップ（CPU パワーアップ）する時はVMを停止しなければならない。
近接通信配置グループ（proximity placement groups）を使うと、VMを単一のデータセンター内にデプロイすることができる。対象となるVMとproximity placement groups は同一リージョンになければならない。
VM をデフォルトのドライブセッティングで作ると、Cドライブだけが作られる。その後、Dを追加して、そこに入れたファイルはVMをリデプロイすると消える。
Availability Set （可用性セット）に登録されている VM のサイズを変更したい場合、同一 Availability Set に登録されている全ての VM を停止しなければならない。サイズの変更する際、場合によっては VM をホストするハードの変更を伴う可能性がある。Availability Set に登録されている VM たちは、可用性を確実に管理するため同一のハードにデプロイされている。なので、別ハードに移る時はみんな一緒になる。みんな一緒になると、その Availability Set に VMがいつくあるか分からないし、どれだけ時間がかかるかもわからない。なので、VM は全部停止して置け、という理屈。
仮想ネットワークの構成と管理
Azure Virtual Network (Vnet)
VNet をピアリングする時、お互いのアドレススペースがかぶっていたらだめ。例えば、以下の二つはピアリングできない。
VNet1: 10:11.0.0/16
VNet2: 10:11.0.0/17
Vnet は Azure 内の仮想ネットワーク。Vnet を作る時、アドレススペースを指定する。例えば10.0.0.0/16のように。で、Vnetの中に必ずサブネットを作成する必要用がある。なので、Vnet > subnet という関係。Vnet の中には複数のsubnet を作成することができる。例えば subnet1 = 10.0.0.0/24 で subnet2 = 10.0.1.0/24 のように。
同じ Vnet の中ならプライベートIPで通信ができる（もちろん、NSGや Windows Firewallの設定がきちんとしている前提で）。でも異なる Vnet 間ではプライベートIPで通信はできない。パブリックIPを使えば通信はできる
VNet が既にピアリングされている場合、その VNet に新しい Address Space を追加することはできない。一度ピアリングを解除してやる必要がある。
IPアドレスではなくNICを登録するのがキモ。NICには複数のIP、例えばパブリックとプライベートのIPが紐づいている。
ASG (Application Security Group) を使うと、複数VMのIPアドレスをグループ化することができる。
NSG (Network Security Group) をデフォルトで作ると、全ての Inbound をブロックする。ただし、同一VNETからのアクセスはOK。ロードバランサーからのアクセスもOK。一方、Outbound は全て許可。
Azure の Public IP はリージョンに依存している。つまり、あるリージョンで作った Public IP を別リージョンに移すことはできない。別リージョンにある Resource Group に移動させたとしても、その IP はオリジナルのリージョンにとどまる
ロードバランサはBasic LBとStandard LBがある
バックエンドプールはPublic IPを持っているか。Public IPなしで同じ仮想ネットワーク上にあれば*VMにPublic IPアドレスが付与されている時は、候補としてVMが表示されないため、Public IPはデタッチする必要あり
高可用性(HA)ポート
- 負荷分散規則の一種
- stanrdardで対応、Basicでは使用不可
- 内部standard Load Balancerのすべてのポートに到着するすべてのフローの負荷分散を簡単に行う方法を提供
Direct Server Return(DSR)
- LBの機能のひとつ
- クライアントからLB経由でアクセスすれば応答も、サーバ→LB→クライアントとLBを経由する
- DSRを使うとLBを経由せずサーバ→クライアントに直接応答がいく
- LBの負荷分散規則の設定のところで選択できる
- LB側での処理が必要なくなりシステム全体としてスループット向上
Floating IP
- クラスタリング構成の複数のサーバがあるときに、クライアント側にサーバが切り替わったことを意識させないように、クラスタ内で共有してもつ仮想IPのこと
インバウンドNATルール
- 接続時のポート番号が一般的なポート番号を使わなくて済むため、ポート番号を知らないとアクセスできない状態になる
- 接続時のポート番号をサーバーごとに分けるので、目的のサーバーに必ず到達することができる
- LBでPort番号を変換 = インバウンドNAT ex) 5000→22
ARM
- リソースを作成・更新・削除する管理サービス
- PF or API的な立ち回りをしてくれるのですべての異なるツールに一貫性をもたせることができる
ARM Template
- デプロイしたいAzureのリソース、その設定値などをJSON形式で書いておく設計図みたいなもの
- 同じ環境を繰り返し作りたいときに便利
- パスワードとかは、Azure Key Vaultへ
Azureとオンプレミスの接続
Expressroute
- 回線事業者が提供する専用線を使用した通信
- 対応するには、ExpressRouteに対応している回線事業者との契約が必要
- ExpressRouteを介してAzureのサービスを利用するためには、サービスに応じたピアリングを構成する必要がある
- ルータ間で冗長化されており、単一障害時にも通信を継続
- PaaS、SaaSでも利用できる
Azure 資源の監視とバックアップ
Traffic Analyticsを追加できるようにするためには、対象のサブスクリプションに対するReaderロールがあれば事足りる。
Azureログを解析するには、Kustoというクエリ構文を使う。こんな感じ。search in (Event) “error”→Eventテーブルからerrorという文字列を探す。
Azure Import/Export serviceはAzure Blob storage だけExportできる。なので、TableやQueueタイプはImportもExportもできない。
| サービス | 対応ストレージ |
|---|---|
| Import | Blob, File |
| Export | Blob |
- dataset.csv : コピーするディレクトリの一覧またはファイルの一覧を含むcsvファイ
- driveset.csv : マップされるディスクの一覧を含むcsvファイル
Storage Accountにアプリケーションが時間制限付きでアクセスできるようにするにはSAS（shared Access Signature)を使う必要がある
VM のアラートログを監視したい場合、Microsoft Monitoring Agent VM extension をVMに add するのではなく、install する必要がある。
VM のアラートログを監視したい場合、以下の三つの設定をする。
1. Azure Log Analytics workspace を作成する
2. Microsoft Monitoring Agent を VM にインストールする
3. Azure Monitor で監視するアラートを設定し、データソースとして1. で作成した workspace を設定する。
Azure Kubernetes Service (AKS)
簡略化されており、自動アップグレード、スケーリング、自己修復などを簡単に操作なしに利用することできる
マスターはAKSによって管理されるが、ノードは自分で管理する必要あり
コンテナをAKSにデプロイコマンド→$ az acr build
Network Watcher
IP Flow Verify(ネットワーク診断)
- NICとsubnetに適用したNSGの通信可否をシミュレーションできる
- 送信元及び宛先IPv4アドレス、ポート、プロトコル(TCP/UDP)、トラフィックの方向(受信または送信)を指定し接続テストを行う
- アクセスを拒否される時は、NSGに問題がある
接続モニター(監視)
- サーバ間(VM間)での通信可否とRTT継続的に測定し続ける→一回だけなら、「接続のトラブルシューティング」
- VMとIPアドレス間のネットワーク接続を監視する (死活監視)
- 定期的な間隔で通信を監視し、VMとエンドポイントの間の到達性・レイテンシー・ネットワークトポロジー変更通知
- エンドツーエンドの接続監視
- ソースに指定するVMにはNetwok Monitorエージェントがインストールされている
- アラートの作成もできる
ネットワークパフォーマンスモニター (監視)
- ネットワークパフォーマンスを監視
- OMSエージェント間でネットワークの接続性やExpressRouteの性能監視をする機能を備えている
接続のトラブルシューティング(ネットワーク診断)
- 接続モニターの一回バージョン
- VM→VM TCP接続確認できる、到達の可否、接続時の待機時間
- Azure上のVMから宛先を指定して実行すると、VMにログインをしなくてもネットワークの接続性を確認できる
参考
Udemy教材の以下も参考にさせて頂きました。
AZ-104: Microsoft Azure Administrator 試験対策講座
Udemyホームページ
