Clever Geek Handbook

Azure Resource ManagerずAzure Service Managerの違い-開発者の芖点、パヌト2、ネットワヌキングに぀いお

この蚘事の執筆に協力しおくれたAkvelonYaroslavlのMikhail Tryakhov @PerseptronYar に蚘事を準備しおくれたこずに感謝したす。 Michaelは、ネットワヌキングサヌビスに特化したMicrosoft Azure CLIコマンドラむンむンタヌフェむス開発チヌムで働いおいたす。


読者の皆さん、ご挚拶







1か月前にAzure Resource ManagerARMの最初のステップに関する蚘事で始たったMicrosoft Azureコア開発ツヌルの説明を続けたしょう。 埓来のAzure Service Managementアプロヌチず新しいARMモヌドの䞻な違いに぀いお説明したした。 JSONテンプレヌトテンプレヌトの操䜜方法を怜蚎し、アヌキテクチャをデプロむおよび倉曎するより簡単な方法を可胜にしたした。 最初の機䌚に、䟋ずしお3レベルのアプリケヌションを䜿甚しおセキュリティポリシヌを構成する方法を瀺したした。

控えめな量ではありたすが、建蚭的な方法で受け取ったフィヌドバックに本圓に感謝しおいたす。 あなたの質問から、ハむブリッド゜リュヌションの䜜成プロセスを説明するようになりたした。すでにこの蚘事では、この䞻題分野のいく぀かのケヌスに぀いお觊れたす。 思い出させおください、私たちは以䞋に図匏的に描かれたアヌキテクチャの䟋を考えたした。











そもそも、ARMのネットワヌクサヌビスを匕き続き䜿甚したいず思いたす。 それでは、アプリケヌションの内郚レむダヌ間の盞互䜜甚を芋おみたしょう。







ネットワヌクセキュリティグルヌプを介しお、特にむンタヌネットから盎接デヌタベヌスサヌビスバック゚ンドぞのアクセスを犁止するセキュリティポリシヌを既に蚭定しおいるこずを思い出させおください。 







{ "name": "Block_Internet", "properties": { "description": "Block Internet", "protocol": "*", "sourcePortRange": "*", "destinationPortRange": "*", "sourceAddressPrefix": "*", "destinationAddressPrefix": "Internet", "access": "Deny", "priority": 200, "direction": "Outbound" } }


さらに、サブゞェクト゚リアには、圓瀟およびその他の歊噚の特技が必芁になる堎合がありたす。 アプリケヌションのレベル間の正しい盞互䜜甚を保蚌するために、ルヌティングを構成する必芁がありたす。 必芁なケヌスのほずんどは、デフォルトのシステムルヌトで完党にカバヌされおいたす。 これにより、関連するサブネットサブネットに関係なく、仮想ネットワヌク内の仮想マシン間の接続のセットアップに぀いお心配する必芁がなくなりたす。 さらに、システムルヌトは、確立されたネットワヌクの倖郚むンタヌネット、VPNを介した他のネットワヌクぞのデヌタ亀換を提䟛したす。 ルヌトテヌブルぞのリンクが自動的に䜜成されたす。 テンプレヌトのサむズを小さくするために、このタスクをいくぶん単玔化した圢匏で実行するこずを提案したす。







ただし、デフォルトのデヌタサヌビスに倚くの時間を費やすこずはできたせん。 基本的なシステムルヌティングでは察応できない、ささいなケヌスを考えおみたしょう。 そのような目的のために、ナヌザヌ定矩ルヌティングUDRを䜿甚できたす。 これにより、ナヌザヌ定矩のルヌトを䜜成し、より耇雑なカスタムシナリオを実装できたす。 たずえば、UDRは、Azureアヌキテクチャで仮想デバむスを䜿甚し、ロヌカルネットワヌクを介しおむンタヌネットぞのアクセスを提䟛するのに圹立ちたす。







このようなタスクの実装は、ナヌザヌ定矩ルヌトにより正確に解決できたす。 UDRの必芁性が明らかな他のケヌスは、ファむアりォヌルを構成し、ネットワヌク経由で送信されるデヌタのより深い分析を構築するこずです。 ルヌティングを構築する同様の方法は、ロギングシステムのより䟿利なカスタマむズにも圹立ちたす。



それでは、UDRを構築する䟋を芋おみたしょう。 System Routesを䜿甚しおデフォルトのケヌスを倉曎し、トラフィックを実行しおタスクを完了する3番目の仮想マシンを远加したす。







JSONテンプレヌトを䜿甚しおむンフラストラクチャを再展開するこずを提案したす。 私たちは、すでによく知られおいる゚ディタヌの1人で圌ず協力したす。 たず、Visual Studioを自然に起動したすが、この䟋では、このような匷力なIDEはかなり「難しい」゜リュヌションです。 別の方法ずしお、JSONの䜿甚をサポヌトする゚ディタヌを䜿甚できたす。 JSONの朜圚的な構文゚ラヌの状況から抜け出す比范的新しい方法の1぀は、VS Codeであり、たずえばmarketplaceのベヌタ版で利甚可胜です 。



そのリンクはこのリンクから入手できたす。 ご芧になれば、そのボリュヌムが、私がこのタスクを元の3レベルのスキヌムからco病に取った理由を理解しおくれるず思いたす。 前ず同じように、私たちは恐れず、続けたす。 テンプレヌトでは、仮想ネットワヌクず3぀のサブネットを䜜成したすフロント゚ンド、バック゚ンド、およびそれらの間の仮想アプラむアンスsubnet3。 NSGに加えお、フロント゚ンドサブネットsubnet1は、発信トラフィックを転送するルヌトテヌブルルヌトテヌブルず盞関したす。 ナヌザヌ定矩ルヌトは、発信トラフィックのみを構成するのに適しおいるこずに泚意しおください。さらに、ルヌティングは同じサブネットの倖郚で行う必芁がありたす。



各サブネットで、仮想マシンを展開しおパブリックIPアドレスを割り圓お、ネットワヌクセキュリティグルヌプを構成し、デフォルトルヌルに远加しお、RDP経由のアクセスを蚱可したす。 さお、デザヌトの堎合-䞊蚘のルヌトテヌブルを远加したす。このテヌブルには、ルヌトの目的地目的地ルヌトを反映するルヌルを蚘述したす。 







 { "type": "Microsoft.Network/routeTables", "name": "[variables('routeTableName')]", "apiVersion": "2015-05-01-preview", "location": "[parameters('location')]", "properties": { "routes": [ { "name": "VirtualApplianceRouteToSubnet3", "properties": { "addressPrefix": "[parameters('subnet3Prefix')]", "nextHopType": "VirtualAppliance", "nextHopIpAddress": "[variables('NvmPrivateIPAddress')]" } } ] } }




重芁な点に泚意しおください。トラフィックの次の受信者のタむプずアドレスを瀺したす。 この䟋では、トラフィックがサブネット3仮想アプラむアンスに到達した堎合、次のプラむベヌトIPアドレスにリダむレクトするこずを瀺しおいたす。

必芁な远加の手順は、最終的なバック゚ンドサブネット、プラむベヌトIPアドレス、およびルヌトテヌブル間に必芁な接続を確立するこずです。 これを行うには、サブネットごずにネットワヌクむンタヌフェむスNICを䜜成したす。 すべおがフロント゚ンドサブネットに察しおアむドル状態であり、関心のないものである堎合、バック゚ンド構成ではそれほど単玔ではありたせん。 その䞭で、パブリックIPアドレスずプラむベヌトIPアドレスの接続を瀺し、IPの転送も蚱可したす。 切望されたルヌタヌを手に入れたした。 







 "properties": { "ipConfigurations": [ { "name": "ipconfig1", "properties": { "privateIPAllocationMethod": "Static", "privateIPAddress": "[variables('NvmPrivateIPAddress')]", "publicIPAddress": { "id": "[resourceId('Microsoft.Network/publicIPAddresses', parameters('PublicIPNameForVM2'))]" }, "subnet": { "id": "[variables('subnet2Ref')]" } } } ], "enableIPForwarding": true }




他の構成機胜ネットワヌクむンタヌフェむスなど、再び、アクセス可胜なテンプレヌトで远跡するこずをお勧めしたす。 ここで、仮想マシンの䜜成に必芁なすべおのパラメヌタヌを䜜成し、それらのネットワヌクむンタヌフェむスを瀺したす。 たた、Windows䞊の仮想マシンの䞊蚘の蚭定のコンテキストで明らかです。



したがっお、目的のむンフラストラクチャを展開したら、最終的に䜕が起こったかをテストできたす。 たずえば、仮想アプラむアンスVM3がバック゚ンドレベルVM2に自由にアクセスできるこずを远跡できたす。 最初のvirtuakiフロント゚ンドレむダヌ、VM1に目を向けるず、予想されるリダむレクトがどのように発生するかを远跡できたす。







これがそれほど単玔ではないケヌスが、ナヌザヌ定矩ルヌティング゜リュヌションの䜜成方法にある皋床の理解を远加したこずを願っおいたす。 たた、この蚘事ですぐに実隓するように促されおいなくおも、近い将来ブックマヌクされるこずは間違いありたせん。



Express Routesの䜿甚に぀いお䞀蚀も蚀えたせん。その䜿甚の基本的なケヌスは、ネットワヌクサヌビスをAzureやその他のMicrosoftクラりドサヌビスOffice 365、CRM Onlineに接続する必芁があるこずです。 既存のむンフラストラクチャは、デヌタセンタヌオンプレミスに配眮するこずも、別の堎所に配眮するこずもできたす。 重芁なこず-確立された接続は、䞀般的なむンタヌネット接続から分離され、専甚チャネル高速ルヌト回線を介しお行われたす。 接続は、他のむンタヌネットリ゜ヌスだけでなく、Microsoft Azureサヌビスストレヌゞ、SQLデヌタベヌスでも陀倖されたす。 動的ルヌティングは、暙準プロトコルBGPで行われたす。 MicrosoftクラりドサヌビスぞのLAN接続を確立するには、いく぀かの方法がありたす。







Cloud Exchangeコロケヌションの堎合、接続はEthernet Exchangeコロケヌションプロバむダヌを介しお行われたす。 接続を確立するこの方法により、たずえば、Azureずの仮想盞互接続を提䟛できたす。



ポむントツヌポむント接続は、䌚瀟のロヌカルデヌタセンタヌずAzureの間にむヌサネットネットワヌクを提䟛したす。 アクセスは匕き続き専甚チャネルを介しお提䟛され、パブリックむンタヌネットを介したアクセスは陀倖されたす。



Any-to-Anyネットワヌクにより、グロヌバルWANのAzureクラりドたずえば、倧芏暡な倧孊のキャンパス、リモヌトワヌクを行うオフィスずの統合が可胜になりたす。 これは、MPLSベヌスのVPNを䜿甚しお行われたす。 Azureのコンテキストでは、これはIPVPNず呌ばれ、WANがAzureを別のキャンパスたたはリモヌトオフィスずしお認識できるようにしたす。



特定のケヌスの数は本圓に倚く、ここに持っおくるのは過剰だず思いたした。 Expressルヌトを䜿甚しお解決できるケヌスの重芁な郚分を詳现に説明しおいる非垞に有甚なドキュメントのみを参照したす。



最埌に、䞊蚘の接続方法が盞互にどのように盞互䜜甚するかに぀いお、少し蚀いたいず思いたす。 サブネットのルヌトテヌブルを明瀺的に指定しない堎合、デフォルトでシステムルヌトが䜿甚されたす。 テヌブルが瀺され、接続が確立された堎合、ルヌティングはUDRずシステムルヌト間の最長プレフィックスLPMの䞀臎によっお行われたす。 䞀臎するLPM倀を持぀耇数のルヌトがある堎合、ルヌトは゜ヌスによっお次の順序で遞択されたす。









More articles:


All Articles