• 通常のVPC: 標準的なVPC構成

• Classic Access VPC: Classic Infrastructureとの接続が可能なVPC

• *Virtual Private Cloud (VPC)**では、以下のようにネットワーク構成が行われます：

1. Address Prefix:
• Address prefixは、IPアドレスの範囲を定義するもので、VPC内の各ゾーン（Zone）ごとに設定されます。これにより、特定のゾーンで使用するIPアドレスの範囲が決まります。
• 例えば、10.0.0.0/16のように、広い範囲のIPアドレスが1つのaddress prefixとして設定されます。

2. Subnet:
• Subnetは、定義されたaddress prefixから、さらに小さなIPアドレスの範囲を切り出して作成します。
• 例えば、10.0.0.0/24や10.0.1.0/24などがサブネットになります。

3. Zoneごとの制限:
• Address prefixは、特定のZoneに割り当てられるため、サブネットもそのZone内で定義する必要があります。
• つまり、1つのaddress prefixで定義したサブネットは、Zoneを跨って構成することはできません。各ゾーンごとに独立してサブネットを作成する必要があります。

主要な違い：

• 課金方式：IBM Cloudは秒単位の課金を採用しており、より細かい使用時間に応じた課金が行われます。AWSは主に時間単位で課金されますが、リザーブドインスタンスやスポットインスタンスで割引を受けられます。

• IPアドレス予約機能：IBM CloudのReserved IPはVPC内で特定のIPを予約して、再作成しても同じIPを使い続けることができます。AWSでは**Elastic IP（EIP）**が同様の機能を提供します。

• 通信料金：同一リージョン内のZone間の通信については、IBM Cloudでは課金されませんが、AWSでも同じリージョン内のAZ間通信は無料です。ただし、リージョン間通信には両者とも課金があります。

IBM Cloud VPCの制約と推奨事項

1. address prefixの制限
• 各Zoneごとに最大15個までaddress prefixを定義できます。
• もし上限に達した場合、ケースを起票することで制限を引き上げることが可能です。

2. subnetの制限
• 各VPCごとに最大15個までsubnetを作成できます。
• VPC内でsubnetを作成するには、事前にaddress prefixを設定する必要があります。

3. VPC作成時のaddress prefix設定
• VPCを作成する際に、default address prefixを一緒に作成するかどうかを選べます。
• 事前定義されたZoneごとのaddress prefixを避けるため、VPC作成時にdefault address prefixを作成せず、後から手動でaddress prefixを追加することが推奨されます。

4. subnetの作成方法
• Subnetはaddress prefixから切り出して定義する必要があります。そのため、まずaddress prefixを作成してから、その範囲内でsubnetを作成します。

5. VPCで予約されているIPアドレス
• Subnet内のすべてのIPアドレスが利用できるわけではなく、特定のアドレスがIBMによって予約されています。
• 例えば、10.10.10.0/24のaddress prefixの場合：
• 10.10.10.0: ネットワークアドレス
• 10.10.10.1: ゲートウェイアドレス
• 10.10.10.2: IBMによって予約
• 10.10.10.3: 将来の使用のためにIBMによって予約
• 10.10.10.255: ブロードキャストアドレス

リンクと参考資料

• 詳細な設定方法やクォータに関しては、以下のリンクを参照してください。
• VPCのクォータ設定
• address prefixの設定方法
• Classic Infrastructureとの接続設定
• VPCの予約IPアドレス

まとめ

• VPCとsubnetを作成する際には、事前にaddress prefixの範囲を決定し、その範囲内で必要なIPアドレスを割り当てる設計が重要です。

• Reserved IPやdefault address prefixに関する注意点を押さえて、VPCの設計を行うと、後々のトラブルを避けやすくなります。

3-2. コンピュート（計算リソース）（VPC） - VSI（仮想サーバー）

VSIの種類

• Balanced: 計算、メモリ、ネットワークバランスが取れた基本的なインスタンス

• Compute: 計算リソースが強化されているインスタンス（CPU集中的な処理向け）

• Memory: メモリリソースが強化されているインスタンス（メモリ集中的な処理向け）

• GPU: グラフィック処理やAI、機械学習向けのGPU搭載インスタンス

• Very High Memory: 高メモリ容量を持つインスタンス（大規模なデータセットの処理向け）

• Ultra High Memory: 超高メモリ容量を持つインスタンス（非常に大規模なデータセットや高度な処理向け）

• Storage Optimized: ストレージ性能が強化されているインスタンス（I/O集中的なアプリケーション向け）

課金と割引

• 自動割引: VSIの利用時間に応じた自動割引が提供されます。具体的には、長時間利用することで割引率が適用されます。

• suspend billing: 一時的にVSIを停止しても、課金が一時的に停止される機能（suspend billing）が提供されています。これにより、不要なコストを削減することができます。

スクリプトによる自動作業実行

• User Data: VSIのプロビジョニング時に、「User Data」内にスクリプトを記載することができます。これにより、VSIが作成された際に自動的に指定した作業（例えば、ソフトウェアのインストールや設定変更など）を実行することができます。

障害対応

• ホストサーバー障害時の対応: ホストサーバーに障害が発生した場合、VSIは数分以内に自動的に別のホストサーバーで再起動を試みます。これにより、高い可用性が確保されています。

参考リンク

• VSIのプロファイルについて

• VSIに関するFAQ

• Qiita記事（VSIの利用に関する参考情報）

まとめ

• ストックイメージ：IBM Cloudが提供する標準のOSイメージ

• カスタムイメージ：ユーザーが作成したカスタムOSイメージ

• カタログイメージ：他のアカウントで作成されたイメージ

• スナップショット：既存のボリュームのスナップショットを基にしたイメージ

• 既存のボリューム：既存のブートボリュームを使ってVSIを作成

コンピュート（VPC） - 追加機能と設定

1. Placement Group

• Host Spread:
• 目的: 各VSIインスタンスが異なる物理ホストに配置されるようにする。
• 特長: 同一の物理ホストでVSIが動作しないことを保証します。
• 制限: 1つのPlacement Groupに最大12VSIインスタンスまで収納可能です。

• Power Spread:
• 目的: 各VSIインスタンスを異なる物理ホストに配置し、さらに電源レベルでも異なる環境に配置します。
• 特長: より強力な冗長性を提供します（電源レベルのAnti-Affinity）。
• 制限: 1つのPlacement Groupに最大4VSIインスタンスまで収納可能です。

2. Hyper-Threading（HT）

• VSIはデフォルトで**Hyper-Threading（HT）**が有効化されています。これにより、1つの物理コアで複数のスレッドを並列処理することが可能となります。

• HTを無効化したい場合は、必要に応じて設定を変更することができます。アプリケーションによっては、HTがパフォーマンスに影響を与えることがあるため、無効化するケースもあります。

• 詳細な手順はHyper-Threadingを無効化のリンクをご覧ください。
💡
• 通常のCPUコアは、1つの処理しか同時に実行できません。
• Hyper-Threadingを使うと、1つの物理コアが2つの処理を同時に扱えるようになります。つまり、処理が並列に実行され、パフォーマンスが向上します。

3. ハイパーバイザーのメンテナンス

• IBM Cloud VPCでは、ハイパーバイザーのメンテナンス中に、Live Patchが適用できない場合があります。その場合、Live Migrationを行ってVSIを別のホストに移動することで、利用者がほとんど意識することなく運用が行われます。

• ただし、メンテナンス内容によってはVSIの再起動が必要な場合があります。その際、スケジュールメンテナンスとして事前に通知されます。

• 詳細はCloud Maintenanceについてをご参照ください。
💡
こちらの内容を簡単に説明します。
1. Live PatchとLive Migration
• Live Patch（ライブパッチ）: サーバーが動作している最中に、システムの更新や修正を行うことができる機能です。通常、サーバーを停止せずに更新できるので、サービスの中断を避けられます。
• Live Migration（ライブマイグレーション）: サーバー（VSI）が動作中に、別の物理サーバー（ホスト）に移動する技術です。これもサービスの停止なく、別の場所に移動できるため、利用者にはほとんど影響がありません。
2. ハイパーバイザーのメンテナンス
• ハイパーバイザーは、仮想マシンを動かすためのソフトウェアです。このハイパーバイザーがメンテナンスを受けることがあります。メンテナンス中に「Live Patch」が適用できない場合、システムは動作し続けるものの、メンテナンスを行うためにサーバーを移動する必要があります。
3. VSIの再起動が必要な場合
• メンテナンスによっては、サーバーを移動（Live Migration）するだけでは対処できないこともあります。その場合、サーバーを再起動する必要があり、その際は事前に利用者に通知されます。
まとめ
IBM Cloud VPCでは、サーバーのメンテナンス中、サービスの停止を避けるために「Live Migration」でサーバーを移動させることができますが、もしメンテナンス内容によっては再起動が必要な場合、その場合は事前に通知されます。

まとめ

• Placement Groupを使用することで、VSIが同一の物理ホストに配置されないように設定でき、冗長性と高可用性が向上します。

• *Hyper-Threading（HT）**はデフォルトで有効ですが、無効化も可能です。特定のアプリケーションに最適化するための柔軟性があります。

• ハイパーバイザーのメンテナンス時には、Live Migrationを通じてほとんどの操作が透過的に行われ、利用者への影響を最小限に抑えます。

3-2. コンピュート（VPC）: 専有ホスト（Dedicated Host）

• 専有ホストは、利用者に特定の物理サーバーを専用に割り当てるオプションです。これにより、仮想サーバー（VSI）を他の利用者と共有せず、専用のリソースでプロビジョニングできます。

主な特徴:

1. 専有ホストの選択
• 利用者は、事前に予約された物理サーバー（専有ホスト）を利用してVSIを作成できます。

2. 専有ホストグループ
• 専有ホストは、必ずdedicated host groupに属する必要があります。各ゾーンごとに専用のホストグループが構成され、共通のサーバープロファイルを使用します。

3. ホストの指定
• サーバー注文時には、以下の2つの選択肢があります。
• 「Specify host」：特定のホストを指定
• 「Specify group」：専有ホストグループを指定

4. 複数VPCでの共有利用
• 専有ホストは、自アカウント内の複数のVPCで共有することが可能です。

5. VSIの移動
• *「Specify group」**で注文したVSIは、Instance placement属性を一時的にdisabledにすることで、別の専有ホストに移動することが可能です。

6. 専有ホストの物理障害
• 専有ホストに物理障害が発生した場合の挙動については、詳細な情報が提供されています。リンクから参照できます。

7. Quota（割り当て制限）
• 専有ホストは大量のvCPUを事前に割り当てる必要があります。そのため、VPCのQuota（現状、1リージョンあたり200vCPU）に引っかかりやすいです。Quotaを引き上げるためには、事前にCaseを起票して上限を引き上げてもらうことが推奨されています。

参考リンク:

• 専有ホストの詳細: IBM VPC FAQ - Dedicated Host

• 専有ホスト作成ガイド: Creating Dedicated Hosts

• VPCのQuota制限について: VPC Quotas

Auto Scale

• 最大100台までのVSIを動的または静的に自動スケール可能。

• *VPC Load Balancer（ALB/NLB）**と連携可能。

Instance Template

• 展開するVSIの雛形（テンプレート）として以下を定義：
• プロファイル（vCPU/Memory）
• SSH鍵
• Security Group
• User Data

• Instance Groupを使わなくても単独で利用可能。

Instance Group

• インスタンステンプレートを元にスケール設定を定義。

• スケーリング方法：
• 静的: 0～100台の範囲を指定
• 動的: 最大値、最小値、集計期間、クールダウン期間、メトリック（CPU使用率、メモリ使用率、Network流量）を指定。
• スケジュールベースの増減も可能。

• 制約：
• Secondary network interface、floating IP、data volumeはサポートされていない。

ベアメタルサーバー

• 選択可能なカテゴリ:
• Balanced
• Compute
• Memory

• 課金:
• CPU、メモリ、ストレージ、NICは時間課金制。
• Network bandwidthは、10/25/50/100/200Gbpsから選択可能。
• 利用時間に応じた自動割引が適用されるが、suspend billingは利用できない。

• 機能:
• TPM（Trusted Platform Module）やSecure Bootがサポート。
• User Data内にスクリプトを記載し、プロビジョニング時に自動作業を実行可能。

• 周辺サービス:
• Security Groups, ACL, Load Balancer, Public Gateway, Floating IP, Transit Gateway, Direct Link 2.0 などと組み合わせて利用可能。

VSIのストレージ

1. Block Storage

• Boot Volume:
• サイズ: 100〜250 GB
• IOPS性能: 最大3,000 IOPS

• Data Volume:
• 最大ボリューム数: 12個
• Tier構成（IOPS性能とサイズ）:
• 3 IOPS/GB: サイズ 10GB〜16,000GB
• 5 IOPS/GB: サイズ 10GB〜9,600GB
• 10 IOPS/GB: サイズ 10GB〜4,800GB

• Custom構成（カスタマイズ可能なサイズとIOPS性能）:
• サイズ: 10GB〜16,000GB
• IOPS性能: 100 IOPS〜48,000 IOPS（サイズにより範囲が変動）
• Snapshot: データのスナップショット取得が可能

2. 暗号化オプション

• Provider Managed (IBM管理鍵): FIPS140-2 Level 2 準拠

• Key Protect (ユーザー鍵持ち込み): FIPS140-2 Level 3 準拠

• Hyper Protect Crypto Services (ユーザー鍵持ち込み): FIPS140-2 Level 4 準拠

3. 注意点

• 共有ストレージ: VPCでは、複数のVSIからアクセス可能な共有ストレージは提供されていません。各Block Storageは、1つのVSIからのみアクセス可能。

• KMSシステムの障害時の挙動:
• Key ProtectやHyper Protect Crypto Servicesにアクセスできない場合でも、**DEK（Data Encryption Key）**はハイパーバイザー上のメモリにキャッシュされており、VSIが稼働していればストレージへのアクセスが継続可能。
• ただし、VSIが停止した場合（再起動や電源断など）、DEKはメモリ上から削除されるため、VSI起動時にKMSシステムにアクセスできない場合は、ストレージにアクセスできなくなります。

1. Image from Volume

• 用途: VSI（仮想サーバー）の構成や設定（OS、アプリケーションなど）をテンプレートとして保存し、新しいVSIを作成するために使用。

• 含まれるもの: Boot Volume（OSや設定）

• 含まれないもの: Data Volume（データボリューム）

2. Snapshot

• 用途: VSIやボリュームの状態をバックアップして、データや構成の復元を行うために使用。

• 含まれるもの: Boot VolumeとData Volumeの両方

• 特徴: データの一貫性を保ったバックアップが可能、復元時に「Fast Restore」オプションで高速復元ができる

まとめ

• Image from VolumeはVSIの構成を保存するためのテンプレート化。

• SnapshotはVSIやボリュームの状態をバックアップし、データ復元が可能。

• Consistency Group: 複数のボリュームを同時にスナップショットし、一貫性のあるバックアップを作成する機能。

• Fast Restore: スナップショットからの復元を事前にクローンを使って高速化するオプション。

• 内蔵ディスク:
• 960GB SSDがブート領域として使用されます。
• オプションで、vSAN向けにNVMe SSDを選択可能。
• ベアメタルの内蔵ストレージは、ユーザー管理が必要で、IBMによる管理は行われません。

• 制限:
• Block Storageはサポートされていません。
• File StorageはVPCのアクセスモードのみサポートされ、2023年8月時点ではSecurity Groupアクセスモードはサポートされていません。

• vNICの最大数:
• 2-16 vCPUs: 最大5個
• 17-48 vCPUs: 最大10個
• 49 vCPUs以上: 最大15個

• 制限:
• IPv6は利用できません。
• Multicastは利用できません。
• vNICの追加/削除は可能ですが、最初に割り当てたvNICは削除できません。

• 帯域幅 (Bandwidth):
• インスタンスの帯域幅の上限はプロファイルに依存し、**Volume bandwidth（ストレージアクセス）とNetwork bandwidth（ネットワークアクセス）**の合算です。
• 帯域幅配分は後から変更可能です。
• 最大帯域幅は、プロファイルにより最大80Gbpsまで選択できます。
• 1vNICあたりの上限は25Gbps。例えば、48Gbpsが割り当てられていても、NICが1つだと25Gbpsが最大。複数NICの場合、例えば2つなら24Gbps x 2、3つなら16Gbps x 3となります。

ベアメタルサーバーのNIC（ネットワークインターフェースカード）の特徴

1. NICの種類:
• PCIインターフェース: これは物理的なネットワーク接続のポートです。実際には仮想化技術を使って、コンピュータのOSにネットワークポートがあるように見せています。
• VLANインターフェース: こちらは、特定のネットワーク（VLAN）を識別するために使われる仮想のポートです。このインターフェースは、PCIインターフェースに関連付けて使用します。

2. 設定可能な数:
• PCIインターフェースは、最大で8つまで設定できます。
• PCIインターフェースとVLANインターフェースを合わせて、最大25個まで作成できます。ただし、もしCLI（コマンドライン）を使うと、128個まで設定可能ですが、これにはパフォーマンスへの影響のリスクがあります。

3. 推奨:
• もし、たくさんのVLANインターフェースを使用したい場合は、ネットワーク仮想化技術（VMware NSXなど）を使用した方が良いです。これにより、効率的にネットワークを管理できます。

まとめ

• ベアメタルサーバーでは、物理的なネットワーク接続を仮想化して設定します。

• 通常は8つの物理インターフェースと、合わせて25個のインターフェースまで設定できます。

• 多くのVLANインターフェースを使うなら、専用のネットワーク技術を使うことをお勧めします。

1. PCI Interface/VLAN Interfaceと冗長化

• SmartNIC内で冗長化されているため、利用者側で特別な設定や対応は不要です。つまり、ネットワーク接続が自動的に冗長化され、安定性が確保されています。

2. Security Groupの適用について

• Security Groupは、SmartNIC内で機能しますが、仮想環境であるESXi内のVM間通信（仮想スイッチ間での通信）では、セキュリティグループが適用されません。 例えば、同じホスト内のVM同士の通信はセキュリティグループで制御できないということです。

3. VLANとSubnetの1:1対応がベストプラクティス

• VLANとSubnetは基本的に1対1の関係にするのが推奨されます。 複数のSubnetを1つのVLANに紐づけることは可能ですが、逆に1つのSubnetを複数のVLANに紐づけると、予期しない問題が発生する可能性があります。

4. Floating IPとInfrastructure NAT

• 通常、インターネットからのFloating IP宛の通信は、VPCの内部Gatewayを経由して、サーバーに転送されます。

• Infrastructure NATを使用すると、内部Gatewayを経由せずに、Floating IP宛の通信を直接ベアメタルサーバー（BM for VPC）に転送することができます。 これにより、例えばVMware NSXを使用している場合、T0ルーターが直接そのパケットを受け取り、処理を行うことができます。

• Elastic IP vs Floating IP: 両者ともインターネットとの双方向通信を提供しますが、AWSのEIPはより柔軟にインスタンス間で移動可能です。IBM CloudのFloating IPは、1つのVSIに固定されるため、移動や割り当ての制限があります。

• Internet Gateway vs Public Gateway: AWSのIGWは、インターネットとVPC内のリソースの双方向通信をサポートしますが、IBM CloudのPublic GatewayはOutbound通信専用です。IBM Cloudでは、Floating IPを使ってインターネットとVPCのリソースを通信させる方法が推奨されています。

Flow Logsの概要

取得できるレベル

• VPCレベル: VPC全体の通信に関するログを収集できます。

• Subnetレベル: 特定のサブネット内で発生した通信に関するログを取得できます。

• Instanceレベル: 特定のインスタンス（VMやベアメタル）に関連する通信のログを取得できます。

• Interfaceレベル: 特定のvNICに対するログを収集できます。

ログの収集頻度

• ログは、5分ごとに収集されるか、100 KBに達した時点で収集されます。これにより、リアルタイムに近い形で通信の情報を追跡できます。

ログの保存先

• ログは**IBM Cloud Object Storage (ICOS)**に保管されます。

• Region制限: ICOSバケットはVPCと同一のリージョンに存在する必要があります。クロスリージョン（別リージョン間）での保存はサポートされていません。

サポートされるプロトコル

• TCPとUDPはサポートされていますが、ICMP（Pingなど）はサポートされていません。

ベアメタルサーバーのサポート

• ベアメタルサーバーは、Flow Logsに対応していません（2022年2月時点）。

活用例

• セキュリティ: ネットワーク上の不審な通信パターンを特定するのに役立ちます。

• トラブルシューティング: 特定のインスタンスやネットワークに関する通信ログを分析することで、問題の特定と解決が容易になります。

• パフォーマンス監視: ネットワークトラフィックの流れを把握し、必要に応じてリソースの最適化を行うことができます。

Load Balancerの種類

1. Application Load Balancer (ALB)
• 用途: HTTP、HTTPS、TCPトラフィックのロードバランシング。
• 特徴:
• Reverse Proxy型: クライアントとバックエンドインスタンスの間に逆プロキシとして動作します。
💡
簡単な違い
• プロキシは、あなたがインターネットにアクセスするために使うもので、代わりにアクセスして結果を返すもの。
• 逆プロキシは、外部からのリクエストを受けて、内部のサーバーにそれを転送して結果を返すもので、主にサーバー側で使われる仕組みです。
• SSL Offload機能: ALBはHTTPSのSSL暗号化をオフロードでき、バックエンドのサーバーに負荷をかけずにSSL処理を行います。
• リスナー: HTTP/HTTPS（SSLオフロード機能あり）、TCPをサポート。
• ポリシー制御: HTTP/HTTPSの場合、リクエストに対してポリシーを制御可能。
• バックエンドプール: HTTP、HTTPS、TCPをサポート。負荷分散アルゴリズム（例: ラウンドロビン、重み付けラウンドロビン、最小接続数）を選択できます。
• セッションスティッキネス: ソースIPベースでセッションの一貫性を保持できます。
• 自動スケーリング: 負荷に応じてインスタンス数（IPアドレス）が自動的に増減します。

2. Network Load Balancer (NLB)
• 用途: TCP/UDPトラフィックのロードバランシング。
• 特徴:
• Direct Server Return型: クライアントからのリクエストがバックエンドに直接送られ、バックエンドサーバーが応答する形です。
• TCP/UDPのサポート: 主にTCPやUDPプロトコルを扱います。
💡
Reverse Proxy型 (Reverse Proxy)
クライアントのリクエストは最初に逆プロキシサーバーに届き、逆プロキシがそのリクエストをバックエンドサーバーに転送します。バックエンドサーバーからのレスポンスも逆プロキシを通してクライアントに返されます。
用途: セキュリティ、負荷分散、SSLオフロードなど。
Direct Server Return型 (DSR)
リクエストは最初にロードバランサーに届き、その後、ロードバランサーはリクエストを直接バックエンドサーバーに転送します。バックエンドサーバーからのレスポンスはロードバランサーを介さず、直接クライアントに返されます。
用途: 高速なレスポンスが求められる場合や、帯域幅が重要なシーンで使用されます。

まとめ

• ALBは主にウェブアプリケーションやSSLオフロードを必要とする場合に使用され、NLBは低レベルなTCP/UDPトラフィックを効率的に扱うことができます。それぞれのニーズに応じて選択することが重要です。

1. DNS Type = Publicの場合
• IBM Cloudが提供するmanaged DNSが使用されます。ユーザーから直接参照することはできません。
• FQDN（完全修飾ドメイン名）は「lb.appdomain.cloud」という形式で提供されます。
• インターネット上のDNSから名前解決が可能です。

2. DNS Type = Privateの場合
• ユーザーが管理するDNSサービスを使用できます。
• ユーザーが指定した任意のドメインを利用できますが、VPC内部からのみ名前解決が可能です。
• VPC外部から名前解決を行う際には、DNSサービスのcustom resolver機能を使います。
• DNSレコードは自動的に生成されますが、ユーザーが直接修正・削除することはできません（修正すると同期されなくなります）。

3. 注意点
• Public LB（インターネット向けロードバランサー）とPrivate LB（VPC内部向けロードバランサー）どちらにもDNS TypeとしてPublicまたはPrivateを選択できます。
• 注文後でも、DNS Typeは変更することが可能です。

ALB/NLBのヘルスチェック設定

• 対象: バックエンドプールごとに設定

• 設定項目:
1. プロトコル:
• ALB: HTTP/HTTPS/TCP
• NLB: HTTP/TCP
2. パス: HTTP/HTTPSの場合、デフォルト「/」
3. ポート番号: ヘルスチェック用ポート
4. 実行間隔: ヘルスチェック実行の間隔（秒）
5. タイムアウト値: タイムアウト（秒）
6. 最大リトライ数: 最大リトライ回数

• 注意点:
• HTTP/1.0が利用され、サポートしない場合はTCPを使用

Private NLB（内部向けのネットワークロードバランサー）を使うときの注意点

1. Ingress Custom Routing Tableを作る理由
• Ingress Custom Routing Tableは、外部（VPCの外や他のネットワーク）からのアクセスを許可するための設定です。
• もし外部からPrivate NLBにアクセスがある場合、事前にIngress Custom Routing Tableを作っておくと、安全にアクセスできるようになります。

2. なぜ事前に作る必要があるのか？
• *Failover（障害発生時）**が起こると、NLBが自動的にルート（道筋）を追加する必要があります。そのため、最初からルート設定をしておくと、問題が起きません。

3. 同じVPC内だけの場合
• 同じVPC内でアクセスが完結する場合、Ingress Custom Routing Tableは必ずしも必要ではありません。
• でも、万が一外部からアクセスが来るかもしれないので、作っておくと安心です。

まとめ

• 外部からアクセスがあるかもしれない場合、Ingress Custom Routing Tableを事前に作っておくと、Failover時に問題が起きにくくなります。

1. x86サーバーからPowerVSへのロードバランシング
• Direct Link 2.0で外部からIBM Cloudへの接続。

2. インターネットからPowerVSへのロードバランシング
• インターネットからPowerVSにトラフィックを分散。

3. Classic Infrastructureへのロードバランシング
• Transit Gatewayを使用してClassic Infrastructureと接続し、トラフィックを分散。

1. セッションスティッキー（Source IPベース）

• バックエンドサーバーの数が変更されると、セッションの割り振りが変わることがあります。

2. ALBのサブネット変更

• ALBは、プロビジョニング後でもサブネットを変更でき、Zone間の再配置も可能です。

3. セッションパーシスタンス（Cookieベース）

• HTTP Cookie Persistence：ALBが設定するIBMVPCALBというCookieでセッションを維持。

• Application Cookie Persistence：Webサーバーが発行するCookieでもセッション維持。

4. HTTPSのセキュリティ

• HTTPS使用時、CookieにはSecureとSameSite=None属性が追加されます。

1. デフォルトのコネクションタイムアウト

• ALBでは、デフォルトで50秒のコネクションタイムアウトが設定されています。バックエンドサーバーからの応答が50秒以上ない場合、コネクションが切断されます。

2. タイムアウトの変更

• 変更可能範囲：50秒〜7200秒（2時間）の間で設定可能です。Listenerの設定で変更できます。

• 7200秒以上に設定したい場合は、サポートにケースを起票する必要があります。

3. タイムアウトの対象

• このタイムアウトはアプリケーション層で適用されます（ネットワーク層ではありません）。

• TCP KeepAliveパケットは、5秒ごとにクライアントとサーバー両方にALBから送信されています。

参考リンク

• コネクションタイムアウト設定について

• TCP KeepAliveについて

ALBのネットワーク障害時の回避策

• AZ1でネットワーク障害が発生すると、AZ1のALBインスタンスのIPアドレスがDNSから返され、通信に失敗する可能性があります。ALB自体は正常に稼働しているものの、障害が発生したAZ1のインスタンスへアクセスが試みられるためです。

• ユーザーが自分のFQDN（完全修飾ドメイン名）を使ってALBにアクセスしている場合、通常はCNAMEレコードを利用してALBのDNSにアクセスします。

• CNAMEレコードを一時的に、正常に通信可能なAZ2のALBインスタンスのIPアドレスに書き換えることで、AZ1での障害を回避できます。この場合、CNAMEレコードをAレコードに変更します。

• 注意点: 将来的にALBインスタンスの数が変わったり、IPアドレスが変更されたりする可能性があるため、障害が回復したら、元のCNAME構成に戻す必要があります。

• 一時的な回避策として、DNS設定の変更（CNAME → Aレコード）が有効。

• 障害回復後には元の設定に戻す必要あり。

前段のロードバランサーからALBへの接続時の注意点とNLBによる回避策

ALB配置時の問題点:

1. 1つのALBをAZまたぎで配置:
• FQDNの使用: 前段のロードバランサー（例: CIS）でALBを呼び出す際、ALBのFQDNを利用してヘルスチェックが行われます。
• 障害時の問題: AZ1のALBインスタンスに障害が発生すると、ヘルスチェックがそのインスタンスのIPアドレスを参照する可能性があり、これによりALB全体へのアクセスが一時的に不可となる場合があります。
• ダウンタイムの原因:
• ALBが障害インスタンスのレコードをDNSから削除するまでの時間。
• DNSクライアント（前段のロードバランサー）が新しいDNSレコードを参照するまでの時間（TTLに依存）。

NLBによる回避策:

1. NLBをAZごとに配置:
• Origin Serverとして、2つのNLB（それぞれAZ1、AZ2のVIP）を登録します。
• 障害時の挙動:
• AZ1のNLBに障害が発生しても、AZ2のNLBへのヘルスチェックが成功するため、アクセスは継続して可能です。
• これにより、前段のロードバランサーがAZ1の障害を認識した場合でも、AZ2を経由してバックエンドサーバーに接続できます。

2. ALBの代わりにNLBのVIPを利用:
• ALBの代わりにNLBのVIPを用いることで、前段のロードバランサー（CIS）が各AZに配置されたNLBへヘルスチェックを行い、障害時でもアクセスを維持できます。

推奨アプローチ:

• Global Load Balancerでの設定: ALBの代わりに、DNSのCNAMEレコードを前段のロードバランサーに設定することで、障害時でもどちらかのALBインスタンスに継続してアクセスできる可能性があります。

• eth0（主インターフェース）があるサブネットにそのサーバーが属していれば、NLBにサーバーを登録できます。

• eth1やeth2（追加インターフェース）があるサブネットには、そのサーバーはNLBに登録できません。

特徴：

• 透過的ファイアウォールなどの目的で使用されます。つまり、パケットの内容を変更せず、そのまま目的のサーバーに届けます。

• 途中でNAT処理をしないため、パケットの送信元や宛先IPアドレスは変わりません。

• このモードを使用するには、Custom Route（カスタムルート）を設定して、パケットの転送先を指定する必要があります。

• サービス概要: IBM VPCのSite-to-Site VPNは、マネージドVPNサービスで最大650Mbpsのスループットをサポート。

• サポート機能: IKEv1/IKEv2、SHA-2系認証、AES暗号化、DHグループ14〜24/31、Mainモード、ESPプロトコル、トンネルモード、PFS、Dead Peer Detection。

• 認証方式: 事前共有キー (Pre-shared key)。

• ルーティングモード: ポリシーベース（Active/Standby）とルートベース（Active/Active）。

• 非推奨機能 (2022/9/20): MD5/SHA1認証、Triple DES暗号化、DHグループ2/5。

• 通信範囲: Policy-based VPNは同一Zone内のVSIとしか通信できず、他ZoneのVSIにはアクセス不可。Zone障害対策には各ZoneにVPN Gatewayを作成する必要あり。

• 冗長性: Zone内ではActive/Standby構成だが、Zone間での冗長化はなし。

• VPN接続設定:
• Peer Subnets (リモートサブネット): リモートサイトのアドレス範囲を指定し、Custom RouteでVPN Gateway経由の経路を追加して通信を有効化。
• Local Subnets (ローカルサブネット): VPCのサブネット、IaaSエンドポイント、Cloud Serviceエンドポイントが指定可能。他のネットワーク(Classic Infrastructure等)は非対応。

• 基本構成: Route-based VPNは単一VIPを持つ対向VPNサーバーを前提とし、1つのVPN Gatewayに2つのメンバーがあり、各メンバーが対向ルーターのVIPとトンネルを形成。1つの接続は2本のトンネルで構成。

• 経路設定:
• 割り当てIPが小さいメンバーを優先してegress routeを使用。
• VPCから対向環境への経路はCustom Routeを用い、next hopにVPN connectionを指定。
• 対向VPNサーバーではVTI(Virtual Tunnel Interface)を構成し、/30のsubnetを使用（例: 169.254.0.0/30）。
• 小さいアドレス（例: 169.254.0.1）をVPC側、大きいアドレス（例: 169.254.0.2）を対向側に割り当て。

• 注意点:
• これらのアドレスは対向VPNサーバーのstatic route設定用で、VPC側へのpingは不可。
• Zone外のVSI通信やHA構成については指定記事を参照。

• VPN Gateway構成:
• 専用のSubnetを用意し、少なくとも4つのIPアドレスを確保することを推奨（HAや更新対応のため）。

• 通信要件:
• 必要なポートをNetwork ACLで許可設定。
• 対向VPN機器でNAT-Traversalを有効化する必要あり。

• 注意点:
• 設定変更時、VPN Gateway全体が更新され、すべてのconnectionが再起動される。

• 概要: OpenVPNを利用したManaged ServiceのClient-to-Site VPN。
認証方式と接続方式を選択可能。

• 認証方式:
1. クライアント証明書
2. UserID/ワンタイムパスコード（二要素認証）
3. クライアント証明書 + UserID/ワンタイムパスコード

• 接続方式:
• Split Tunnel: 必要な通信だけVPNを使用、他の通信は通常経路。
• Full Tunnel: すべての通信をVPN経由。

• 通信設定:
• デフォルト: UDP/443（TCPや他ポートも設定可能）。
• Security GroupでVPN Clientの接続元を制限可能。
• 通信先設定:
• Deliver: 通信そのまま配信（同じVPC内など）。
• Drop: 特定通信を禁止。
• Transfer: Source NATを実施し、異なるVPCやService Endpoint、インターネット接続に対応。

Custom Routeによる経路制御の概要

種類別のルート制御方法

1. Site-to-Site VPN (Route-Based VPN)

• ユーザーがVPN Gateway/VPN Connectionをnext hopとして指定する。

• 明示的なルート設定が必要。

2. Site-to-Site VPN (Policy-Based VPN)

• Custom Routing Table (Egress) でVPN GatewayからのルートをAcceptする設定にする。

• 結果:
• Peer CIDRs（対向ネットワーク）が定義された宛先のnext hopが自動的にVPN Gatewayになる。
• VPN Gateway障害時、自動的に待機系のVPN Gatewayに転送するルートに更新。

• 詳細: IBM Cloud Docs - Policy-Based VPN Route Propagation

3. Client-to-Site VPN

• Custom Routing Table (Egress) でVPN ServerからのルートをAcceptする設定にする。

• 結果:
• Client IPv4 Address Poolが定義された宛先のnext hopが自動的にVPN Gatewayになる。
• VPN Server障害時、自動的に待機系のVPN Serverに転送するルートに更新。

• 詳細: IBM Cloud Docs - Client-to-Site VPN Route Propagation

VPC Routing Table 概要

• 目的: VPC内外の通信経路を柔軟に制御。

• 設定項目: 宛先CIDR、Zone、Next Hop、Action（Deliver/Dropなど）。

• ルート種類:
• Egress: VPC内→外の通信。
• Ingress: 外→VPC内の通信。

• 優先度:
1. 最も具体的なCIDRを優先。
2. Priority値（1が最優先、2がデフォルト）。
3. 同条件ならECMP（ラウンドロビン）。

• Security Group：
• インスタンス単位で設定。
• ステートフル：送信元/宛先が関連付けられるため、応答トラフィックは自動的に許可される。
• インバウンドおよびアウトバウンドのルールを指定。

• Network ACL：
• サブネット単位で設定。
• ステートレス：リクエストと応答のトラフィックを個別に設定する必要がある。
• インバウンドおよびアウトバウンドのルールを指定。

• TCP

• UDP

• ICMP

• ALL (TCP/UDP/ICMP)