Qrunchからお引越しした記事です : created_at: 2019-09-02 21:16:06 +0900
ネットワーク周辺は業務でしっかりやったので概ね割愛。
ロードバランサだけ知識不足なため、そこだけは学習する。
仮想ネットワークの構成と管理
> Azure 負荷分散の実装
・Azureの負荷分散は大きく次の4つ
①Public Load Balancer
OSI参照モデル4層(Tranceport層:TCP/UDP)の制御。
インターネットに接している。(パブリックIPアドレスが必要)
②Internal Load Balancer
OSI参照モデル4層(Tranceport層:TCP/UDP)の制御。
VNet内の制御。⇒パブリックIPは不要。
③Application Gateway
OSI参照モデル7層(Application層)の制御。
SSLオフロードやWAF(WebApplicationFirewall)の機能もある。
④Traffic Manager
OSI参照モデル7層(Application層)の制御。
厳密にはロードバランサではない。
DNSレベルでの地理的負荷分散(?)を行う。
・SKUはBasicとStandardの2種類 : 詳細
⇒機能差、性能差の面でStandardにすることが望ましい。
・バックエンドプール
ロードバランサにより負荷分散している同一構成のマシン達のことを指す。
・正常性プルーブ(Health Probe)
負荷分散対象のマシンのうち、どれが正常でどれが死んでいるかを検査する方法。
プルーブ(Probe)は「調べる、精査する」の意味なので、「健康診断」くらい雑に訳しておくと覚えやすい。
・SNAT(送信元NAT)
SNATの機能を持つ。(中から外へのNAT)
DNATとSNATがよくわからなくなるので以下まとめを記載しておく。(我ながらへっぽこ)
SNAT はプライベートアドレスから発生した通信をグローバルアドレスに届ける技術。
プライベートアドレス(S)をグローバルアドレスに書き換えて通信を実現している。
ホームネットワークから外部サービスへの通信等がこれ。DNAT はグローバルアドレスから発生した通信をプライベートアドレスに届ける技術。
グローバルアドレス(D)をプライベートアドレスに書き換えて実現している。
ホームネットワークで web/mail 等のサーバ等を複数台構築してアドレスを一つに見せて外部に公開する場合がこれ。
この機能があるので、Load BalancerのNAT規則を整理すればバックエンドにいる任意のVMにRDPで接近できる。
(3389ポートで接近した場合はVM1、3390ポートで接近した場合はVM2、みたいな制御)
受信NAT規則(Inbound Nat Rule)として構成する。
ちなみに、VM自体にパブリックIPがひもづけられている場合、SNATはしない。
→VMに付いているパブリックIPでの通信を優先する。
・分散モード
①ハッシュベースの分散モード
5要素(送信元IP、送信元ポート、あて先IP、あて先ポート、プロトコル)を元に
ハッシュ値を作成する。そのハッシュ値を元にバックエンドのVMへ分散していく。
→なので、クライントPCの利用ポートが変わるとあて先VMが変わったりする。
②ソース IP アフィニティ モード
2要素(送信元IP、あて先IP)を元にハッシュ値を作成し、その値を元に分散する。
①と違って、クライアントPCのIPアドレスが変わらない限りあて先VMは変わらない。
→処理途中で通信先VMが変わると困るこまる場合はこっち。
リモート デスクトップ ゲートウェイの構成に使うそうな。
・VNet内の負荷分散に使う。FrontEndにPublicロードバランサを置いてWEBアクセスを負荷分散している裏で、
WEBサーバ→複数DBサーバへのアクセス負荷分散を実施するのに使う、など。
・Vnet内で使う、パブリックIPアドレスがない、などを除いて、基本パブリックロードバランサとできることは同じ。
・Web Traffic load Balancer。(なので、WEBアクセスのトラフィック制御での利用しかできない)
・URLベースのルーティングができる。
→例えばURLが
①https:\//xxx/imagesの場合、画像を保管するWEBサーバへ転送
②https:\//xxx/videosの場合、動画を保管するWEBサーバへ転送。
という制御ができる。(すごい)
・SSLオフロードの機能。
→SSL/TLSのエンコード、デコードをサーバから肩代わり。
・複数サイトのホスティングへも対応。
→http:\//contoso.comはcontosoサーバプールへ転送、http:\//fabrikam.comはfabrikamサーバプールへ転送、など。
・WAF(Web Application Firewall)の役割ができる。
→Webサーバへのアクセスにおいて不正な通信内容
(SQLインジェクション、クロスサイトスクリプティングなどの恐れがある通信)を遮断する。
・「DNS ベースのトラフィック ロード バランサー」
というのが、どういうことか全然分からなかったけどこの図を見てやっと分かった。
①クライアントがDNSサーバに問い合わせる。
②DNSサーバはTraffic Managerへ問い合わせる。
③Traffic Managerは定められた分散規則にしたがって、いずれかのエンドポイントのパブリックIPを返す。
④取得したIPアドレスで直接エンドポイントへ接近する。
・この手法をとることで、地理的負荷分散もできる。
→例えば、東日本リージョン、西日本リージョンにそれぞれWEBサーバを配置した構成も実現できる。
・分散方法(ルーティング方法)は次の通り。
①優先順位
基本、プライマリサイトへアクセスさせ、障害時だけセカンダリを使うときはコレ。
②重み付け
均等に分散したりするときはコレ。例えば、本番環境A、本番環境B、トライアル環境Cがある場合。
A:50、B:50、C:1としたときはAかBにアクセスし、Cにはアクセスしない。Aが障害時はBにアクセスする。
Cのトライアルが終了し、一般公開するときはCも50にするだけでよい。
③パフォーマンス
地理冗長しているような構成のとき、「ユーザから最も近いエンドポイント」を指定させるときはコレ。
この後の「地理的」とはちょっと違う。こちらはあくまで「ネットワーク待ち時間」が最も短いルートをいく。
④Geographic(地理的)
DNS クエリの発信元の地理的な場所に基づいて分散させるときはコレ。
アメリカ本社はUSリージョン、日本支社は東日本リージョンへアクセス!という使い方かな。
⑤複数値
エンドポイントがオンプレしかない(IPv4、v6のアドレス指定しかない)場合につかう。
この場合、正常なエンドポイントのアドレスを全て返答してくる。
⑥サブネット
クライアントのIPレンジによってアクセス先を変更したい場合はコレ。
x.y.a.0/24はA環境、x.y.b.0/24はB環境へ行け、ということができる。
・Azure(IaaS、PaaS)以外にオンプレミスのエンドポイントも指定できる。
・Traffic Managerのネスト(入れ子)もできる。
この場合エンドポイントにTraffic Managerを指定する。
→複雑。
・イントラ内では使えないのではないか?
「Traffic Manager のしくみ」で説明したとおり、Traffic Manager エンドポイントとして、Azure の内部または外部でホストされているインターネット接続サービスを指定することができます。 したがって、Traffic Manager は、インターネットに接続されている一連のエンドポイントにパブリック インターネットからのトラフィックをルーティングすることができます。 エンドポイントがプライベート ネットワーク内にある場合 (内部バージョンの Azure Load Balancer など)、またはユーザーが内部ネットワークから DNS 要求を行う場合、Traffic Manager をこのトラフックのルーティングに使用することはできません。
・「軽くさらっておこう」くらいの気持ちで始めたら、大分奥が深い。
・ApplicationGatewayとTrafficManagerの概要が理解できたのは良かった。(何にも分かってなかった)
第3回 | Azure Administratorへの道(2回:Azure MFA) |
第4回 | Azure Administratorへの道(3回:ストレージ関連) |
第5回 | Azure Administratorへの道(4回:仮想マシン) |
第6回 | Azure Administratorへの道(5回:Load Balancer) |
第7回 | Azure Administratorへの道(6回:AzureAD周辺) |
Crieitは誰でも投稿できるサービスです。 是非記事の投稿をお願いします。どんな軽い内容でも投稿できます。
また、「こんな記事が読みたいけど見つからない!」という方は是非記事投稿リクエストボードへ!
こじんまりと作業ログやメモ、進捗を書き残しておきたい方はボード機能をご利用ください。
ボードとは?
コメント