ネットワークの IP アドレス指定を計画する
あなたは、勤務する製造会社で、Azure で必要な仮想マシンの数について運用チームとエンジニアリング チームに質問しました。 また、拡張の計画についてもたずねました。 この調査の結果に基づいて、近い将来に変更する必要がない IP アドレス指定スキームを計画したいと考えています。
このユニットでは、ネットワーク IP アドレス スキームの要件について説明します。 クラスレス ドメイン間ルーティング (CIDR) について、およびそれを使用してアドレス指定のニーズに合うように IP ブロックをスライスする方法について学習します。 次のユニットには、Azure 仮想ネットワークの IP アドレス指定を計画する方法がわかる演習があります。
要件の収集
ネットワーク IP アドレス スキームを計画する前に、インフラストラクチャの要件を収集する必要があります。 これらの要件は、余分な IP アドレスとサブネットを確保することにより、将来の成長に備えるためにも役立ちます。
要件を明らかにするために、次の 2 つの質問をすることをお勧めします。
- ネットワーク上にはいくつのデバイスがありますか?
- 将来、ネットワークにいくつのデバイスを追加する予定ですか?
ネットワークを拡張するとき、IP アドレス スキームを再設計したくはありません。 他に、次のような質問をすることもできます。
- インフラストラクチャで実行されるサービスを基にすると、どのデバイスを分離する必要がありますか?
- サブネットはいくつ必要ですか?
- サブネットあたりのデバイス数はいくつですか?
- 将来、サブネットにいくつのデバイスを追加する予定ですか?
- すべてのサブネットを同じサイズにしますか?
- サブネットはいくつ必要ですか、または今後いくつ追加する予定ですか?
一部のサービスを分離する必要があります。 サービスを分離すると、別のセキュリティ レイヤーが追加されますが、適切な計画も必要になります。 たとえば、フロントエンド サーバーはパブリック デバイスからアクセスできますが、バックエンド サーバーは分離する必要があります。 Azure 内のネットワークを分離するには、サブネットが役に立ちます。 ただし、既定では、仮想ネットワーク内のすべてのサブネットが、Azure 内で相互に通信できます。 さらに分離するには、ネットワーク セキュリティ グループを使用できます。 データとそのセキュリティ要件に応じて、サービスを分離する場合もあります。 たとえば、人事データと会社の財務データを、顧客データベースから分離することができます。
要件がわかれば、サブネットごとのネットワーク上のデバイスの合計数と、必要なサブネットの数を、いっそう正確に把握できます。 CIDR では、元の IP アドレス クラスのシステムよりも、柔軟性のある IP アドレスの割り当てが可能です。 要件に応じて、IP アドレスのブロックから必要なサブネットとホストを決定します。
Azure では、各サブネットで最初の 3 つのアドレスが使用されることを思い出してください。 サブネットの最初と最後の IP アドレスも、プロトコル準拠用に予約されています。 そのため、Azure サブネットで使用可能なアドレスの数は (2^n)-5 個です。n は、ホスト ビットの数を表します。