利用中の Azure 仮想ネットワークを変更する

はじめに Azure 上で IaaS ベースのシステムを構築・運用されているお客様から「既に仮想マシンが配置されている仮想ネットワークのアドレスを変更したいんだけどどうすればいいの?」というご質問をたまにいただきます。そのご質問の背景として代表的なものは以下のようなものが挙げられます。 仮想ネットワークを小さく(あるいはサブネットを大きく)作りすぎて、新しいサブネットが追加できなくなった サブネットを小さく作りすぎて、内部に配置されている仮想マシンがスケールアウト出来なくなった 接続したい別のネットワーク(オンプレミスや別の仮想ネットワーク)とアドレスレンジが衝突してしまった 仮想ネットワークのアドレス計画は慎重に、といった注意喚起をすることが本ブログの趣旨ではありません。もちろん計画的であるにこしたことはありませんが、構築段階でうっかりこのような状況に陥ってしまうことは私の実体験としても良くあります。以降ではある程度構築が進んでしまったシステムのネットワーク構成変更における TIPS をご紹介したいと思います。 出来ること出来ないこと Azure 仮想ネットワークは SDN らしく構成に柔軟性がありますが、仮想マシンが配置されていると変更にいろいろと制約が出てきます。その最たるものがこちらの FAQ にあるように “仮想マシンが配置されているサブネットは変更・削除が出来ない” になります。しかし裏を返せば以下の変更は可能であるということになります。 仮想マシンが配置されていないサブネットであれば、他のサブネットと重複しない限り、アドレス範囲の変更や削除が可能 仮想ネットワーク全体に対しては、既存のサブネットのアドレス範囲を含んでいる限り、アドレス空間の拡張や追加が可能 仮想ネットワーク内に空いているアドレス空間があれば、新規のサブネットを追加することが可能 また再起動を伴いますが、仮想マシンを現在のサブネットから別のサブネットへ移動することが可能です。これらの操作を組み合わせることで理想的なネットワーク構成に修正していくことが出来るわけです。 サブネットを追加・削除する まず簡単なところから行くと、仮想ネットワークのアドレス空間に空きがあれば、新規のサブネットを追加することは可能です。またサブネットに仮想マシンが配置されていなければ、サブネットのアドレス範囲の変更や、サブネット自体の削除も可能です。 Azure ポータルでサブネットの追加、削除、アドレス範囲の変更を行うためには、仮想ネットワークのサブネットブレードを使用します。ここでは割愛しますが PowerShell や CLI、ARM テンプレートから同様の操作を行う事も可能です。 仮想ネットワークのアドレス空間を拡張する 前述のような操作は仮想ネットワークのアドレス空間に余裕がある場合に可能ですが、もし足りないならば広げてしまえばよいわけです。アドレス空間が広がれば新規にサブネットを作成できるようになります。例えば下図はセキュリティ上やっぱり Web Application Firewall が必要になった、あるいは運用上 VPN 経由でのメンテナンスが必要になった、ということでサブネットを追加したイメージです。 Azure ポータルでアドレス空間を拡大するためには、仮想ネットワークのアドレス空間ブレードを使用します。ここでは割愛しますが PowerShell や CLI、ARM テンプレートから同様の操作を行う事も可能です。 あとは先ほどのようにサブネットを追加していけばよいわけです。 仮想ネットワークのアドレス空間を追加する これはあまり知られていないかもしれませんが、仮想ネットワークは複数のアドレス空間を持つことが可能です。単にアドレス空間を広げてしまうと、接続先の他のネットワークと重複してしまうようなケースに有効です。こちらもアドレス空間が連続していないだけで考え方としては前述のものと同様です。 仮想マシンを別のサブネットに移動 他のネットワークと接続する必要が後から発覚したが、初期の構築段階では予定が無かったためアドレス空間が重複してしまっていた、ということもありました。どちらか一方のアドレス空間およびサブネットを重複しないものに切り替えてやる必要があるわけですが、各サブネットは仮想マシンがデプロイされているため変更ができません。またそのサブネットを含む仮想ネットワークのアドレス空間も変えることができません。このような場合には以下のステップで変更していきます。 既存と同じ広さを持つ新規のアドレス空間およびサブネットを追加する 仮想マシンを新しいサブネットに移動する 従来から使っていたサブネットとアドレス空間を削除する 仮想ネットワークやサブネットの修正方法は既に紹介していますので、ここで必要なのは仮想マシンを別のサブネットに移動する方法です。仮想マシンが接続されているネットワークインターフェイスの…

0

Azure 仮想マシンにおける可用性の考え方

はじめに 若干今更な感じもするタイトルではありますが、やはり Azure に初めて取り組む方にはわかりにくく、かつ重要視される部分でもありますので、改めてまとめてみたいと思います。「考え方」というタイトルの通り、本記事では技術的にはあまり深入りしないように、なるべく簡潔に記載していきたいと思います。さらに深く追求したい方向けは随所にリンクを貼っておきますので、そちらをご参照いただければと思います。 2017-10-22 追記 本記事の執筆後にも Azure は進化を続けており、可用性ゾーンや計画メンテナンスにおけるセルフサービスといった機能追加や更新が行われました。このため本記事の内容は若干古くなっておりますが、現時点でも通用する内容だと思いますし、可用性に関して選択肢が増えた状況と考えます。特に可用性ゾーンのプレビューが取れある程度知見が得られた段階で本記事を修正するか、別記事を記載しようと思います。 仮想マシン単体レベルの可用性 まず初めに基礎として、1 台だけの仮想マシンで見た場合の可用性についてです。Azure 仮想マシンの可用性を考えるうえでは以下の 3 つの要素が重要です。 Compute CPU やメモリが利用できる Storage  ディスクの読み書きができる Network  当該仮想マシンと通信することができる ちなみにこの 3 つは仮想マシンの課金要素でもありますので、下記もご参照ください。 仮想マシンの課金の仕組み Azure 仮想マシンは Windows Hyper-V をベースとした仮想化基盤上で動作します。Azure ポータルや PowerShell / CLI 等を利用して仮想マシンを作成すると、指定した Azure リージョンのどこかの仮想化基盤上に Compute と Storage リソースが確保され、仮想マシンとしての動作を開始します。この仮想マシンに対してネットワーク接続が可能であることによって、Azure の利用者はサービスを提供することができるわけです。 この仮想化基盤とその上で動作する仮想マシンはデータセンターのオペレーションチームによって監視・運用されています。例えばホストとなる物理サーバーに異常が検知された場合、その内容によっては再起動、あるいは他の健全な物理サーバーへの再デプロイが自動的に行われます。この仕組みは Service Healing と呼ばれ、これは全ての Azure 仮想マシンにおいて標準の機能になります。 サービスの復旧:仮想マシンの自動復旧のしくみ この際、仮想マシンとしても強制的に再起動が発生してしまいますので、一時的にサービスは中断されることになります。つまり Service Healing によるモニタリング間隔+仮想マシンの起動+α 程度のダウンタイムが発生します。ただし再起動先でも同一のOSディスクやデータディスクに接続されるため、そこに格納されたデータが失われることはありません。またネットワーク的にも同条件で再構成されるため、一定時間後には接続可能になりますので、利用を再開することができます。 これは言い換えれば、Azure…

0

Azure App Service の自動スケールと負荷テスト

はじめに クラウドの代表的なメリットの1つは、オンデマンドにリソースを確保することができ、その柔軟なスケーラビリティによって、ビジネスの状況に応じて必要かつ十分な処理能力を得られること、それによって単純なコスト削減だけではなく、コストが最適化できることであると考えます。私の日々のお仕事の中で Azure に関してお客様からご相談を頂くときは、Azure といえば PaaS、PaaS といえば Web Apps (App Service)、という話になることが大変多いです。これは App Service が最初に挙げた“クラウドのメリット” を最もわかりやすく体現しているからであると思いますし、非常にうれしい気持ちになります。本記事では App Service のスケーラビリティとその内部的な仕組みを概説し、負荷の増減に応じて自動的にスケールさせる方法、およびその挙動を検証する方法(ロードテスト)についてご紹介したいと思います。 スケーラビリティ あらためてシステムにおけるスケーラビリティとは、簡単に言えば「利用量や仕事量の変化に対して適応できる能力」のことを意味し、多くの場合以下の 2 つの手法によって実現されます。 スケールアウト/スケールイン(水平スケーリング) スケールアップ/スケールダウン(垂直スケーリング) スケールアウト/スケールインとはサーバー台数を増やす(減らす)ことを意味します。スケールアップ/スケールダウンとはサーバーのスペックを大きくする(小さくする)ことを意味します。これによってシステム全体のキャパシティを調整することで状況の変化に対応するわけです。 私はインフラエンジニアの経験がないのであくまでも想像ではありますが、物理サーバーであればその台数を増減させることは、設置場所、ネットワーク、調達等の関係からなかなか容易でないことは想像に難くありません。またマザーボードが保持する CPU やメモリのソケット数、ディスクを接続するインタフェース数の制限等から、スペックアップも限度がありそうです。もちろん仮想化技術が導入されている場合には柔軟性は高まりますが、やはり最終的には仮想マシンホスト、およびそのクラスタ全体のキャパシティに制約されます。 すなわちこういったスケール調整を実施するために、最初からそれを見越して余裕のある設計をするか、状況が変わったらそこから時間をかけて行う必要があるわけです。前者は余剰のコストが発生するリスクを、後者はビジネス機会の損失が発生するリスクをはらんでいることになります。 Azure App Service のアーキテクチャ App Service の利用形態を非常に乱暴に説明すると、複数の利用者がフロントエンドのロードバランサを共有し、その背後で動作する Web サーバーのプールのなかから数台を占有する形になっています。 占有した Web サーバーに対してアプリケーションを配置しておくと、割り当てられた URL へのリクエストがあった際に、ロードバランサーがそのリクエストを各 Web サーバーに振り分けてくれます。この確保した Web サーバーのスペックと台数を表すリソースが、App Service プラン、そこにデプロイするアプリケーションの容れ物が Web Apps(ないしは API Apps、Mobile Apps 等)と呼ばれます…

0

Azure 仮想マシンで送受信するネットワークパケットをキャプチャする

はじめに Microsoft Azure の IaaS(というか 仮想マシン)を使用したシステムを構築する際に、最も頭を悩ませるのがネットワーク周りの設計です(個人の主観です)。ところが先日 Azure Network Watcher の Public Preview が開始されました。こちらを利用することでネットワークパケットキャプチャを取得し、仮想マシンが実際にどんな通信を行っているのか具体的に把握することが出来るようになります。というわけで本記事ではその利用イメージを紹介していきたいと思います。 取得編 パケットキャプチャを取得するために必要な作業は大まかに以下の4つですが、より詳細な手順に関してはこちらのドキュメントをご参照ください。なお 本記事の 執筆時点では Network Watcher が利用できるリージョンが限られているため、お試しいただく際には仮想マシンや仮想ネットワークを当該リージョンに指定する必要がありますのでご注意ください。 Microsoft.Network リソースプロバイダーの Azure Network Watcher 機能を有効化する Azure Network Watcher を利用するサブスクリプションおよびリージョンを選択する キャプチャを取得したい仮想マシンに拡張機能「Network Watcher Agent for Windows/Linux」をインストールする Network Watcher に上記の仮想マシンをターゲットとするパケットキャプチャを追加する 追加したパケットキャプチャが「実行中」となっている間、当該仮想マシンで発生した送受信のログが拡張機能によって取得され、上記の手順4で指定した仮想マシンのローカルファイルとして、あるいはストレージアカウント上のBlobとして保存されます。 解析編 確認したい通信が完了した頃合いを見計らってキャプチャを停止し、ストレージアカウント等に保存されたファイルを解析用の端末のダウンロードします。このファイルは拡張子 .cap のファイルになっており、Microsoft Message Analyzer や Wireshark 等で内容を確認することができます。下記は Microsoft Message Analyzerで実際にキャプチャファイルを読み込んだ画面です。 中段左側に仮想マシン(10.0.0.4)と通信した相手先毎にグループ化されていますので、それらをドリルダウンしていくことで通信内容を確認することが出来ます。このあたりの解析作業などはオンプレミス環境で実際にネットワークに携わっていた方ならお手の物かと思います。 ちなみに上記は仮想マシンを作成しただけでほぼほったらかしの状態で取得したキャプチャなのですが、それでもいろいろと通信が行われていることがわかります。気持ち悪いですね。このうちのいくつかは Azure 仮想マシンを利用するうえで知っておかないと混乱の元になるものですので、いくつかご紹介したいと思います。 操作端末との通信 前述の図でフォーカスされている一番上のグループになるのですが、これは仮想マシンに…

0

EA 契約における Azure 使用状況と料金をタイムリーに把握しよう

コンサルタントからクラウド・ソリューション・アーキテクト(CSA)と言うよくわからない職種にジョブチェンジして早8か月、 ちょっと Blog とかも書いてみようかと思い立ちました。というわけでここ最近よくご相談いただいた「EA 契約のサブスクリプションだと  Azure  ポータルから料金が見えないんだけど?!」というお話です。それほど目新しい話でも無いのですが、まとまった情報が少ないようなので簡単にまとめてみました。

0

Hello world!

Welcome to Developer Network. This is your first post. Edit or delete it, then start blogging!

1