コンピュート・インスタンスのベスト・プラクティス
Oracle Cloud Infrastructure Computeでは、妥協のないパフォーマンス、柔軟性および制御機能を実現する、ベア・メタルおよび仮想マシン(VM)のコンピューティング性能が提供されます。Oracleの次世代のインターネット規模のインフラストラクチャを搭載し、最も要求の厳しいアプリケーションおよびワークロードをクラウドで開発および実行できるように設計されています。
使いやすいWebコンソール、API、SDKまたはCLIを使用して、コンピュート容量をプロビジョニングできます。コンピュート・インスタンスがプロビジョニングされると、ホストにアクセスできるようになります。これによって、ユーザーがインスタンスを完全に制御できます。
ユーザーはインスタンスに対して完全な管理権限を持ちますが、システムの可用性と高いパフォーマンスを確実に得るために様々なベスト・プラクティスをお薦めします。
Oracleによる使用のために予約されているIPアドレス
特定のIPアドレスはOracle Cloud Infrastructure用に予約されており、アドレス採番方式では使用されません。
169.254.0.0/16
これらのアドレスは、ブートおよびブロック・ボリューム、インスタンス・メタデータ、その他のサービスへのiSCSI接続に使用されます。
クラスDおよびクラスE
224.0.0.0から239.255.255.255 (クラスD)のすべてのアドレスはVCNでの使用が禁止されており、IP標準でマルチキャスト・アドレスを割り当てるために予約されています。詳細は、RFC 3171を参照してください。
240.0.0.0から255.255.255.255 (クラスE)のすべてのアドレスはVCNでの使用が禁止されており、IP標準で将来使用するために予約されています。詳細は、RFC 1112のセクション4を参照してください。
各サブネットにある3つのIPアドレス
これらのアドレスの構成は:
- CIDRの最初のIPアドレス(ネットワーク・アドレス)
- CIDRの最後のIPアドレス(ブロードキャスト・アドレス)
- CIDRの最初のホスト・アドレス(サブネットのデフォルト・ゲートウェイ・アドレス)
たとえば、CIDR 192.168.0.0/24のサブネットでは、次のアドレスが予約されます:
- 192.168.0.0 (ネットワーク・アドレス)
- 192.168.0.255 (ブロードキャスト・アドレス)
- 192.168.0.1 (サブネットのデフォルト・ゲートウェイ・アドレス)
CIDR内のその他のアドレス(192.168.0.2から192.168.0.254)は使用できます。
重要なファイアウォール・ルール
すべてのプラットフォーム・イメージには、Linuxインスタンス上のルートまたはWindowsサーバー・インスタンス上の管理者のみに、インスタンスのブート・ボリュームとブロック・ボリュームで使用されるiSCSIネットワーク・エンドポイント(169.254.0.2:3260, 169.254.2.0/24:3260)に対する送信接続の確立を許可するルールが含まれます。
-
インスタンス上のファイアウォールを再構成してこれらのルールを削除しないことをお薦めします。これらのルールを削除すると、ルート・ユーザー以外または管理者以外が、インスタンスのブート・ディスク・ボリュームにアクセスできるようになります。
-
セキュリティ上のリスクを理解している場合を除き、これらのルールを含まないカスタム・イメージを作成しないことをお薦めします。
-
Ubuntuイメージのファイアウォール・ルールの編集にUncomplicated Firewall (UFW)を使用しないでください。UFWを使用してルールを編集すると、インスタンスが起動しない場合があります。したがって、UbuntuインスタンスがUncomplicated Firewall (UFW)を有効にした後で再起動に失敗するというノートで説明されている方法を使用して、UFWルールを編集することをお薦めします。
システム・レジリエンス
業界全体で行われているハードウェア障害のベスト・プラクティスに従って、ハードウェア障害の発生時にソリューションのレジリエンスを確保してください。ベスト・プラクティスには次のものがあります:
ハードウェア障害が発生したとき、これらのプラクティスに従っていた場合は、障害が発生したインスタンスを終了し、カスタム・イメージを起動して新しいインスタンスを作成してから、バックアップ・データを適用できます。中断されないインスタンスへのアクセス
DHCPクライアントの実行を維持して、常にインスタンスにアクセスできるようにします。DHCPクライアントを手動で停止するか、またはNetworkManagerを無効にする(Linuxインスタンス上のDHCPクライアントが停止される)と、インスタンスはDHCPリースを更新できず、リースの期限が切れたとき(通常24時間以内)にアクセス不可能になります。別の方法を使用してリースの更新を確実に行わないかぎり、NetworkManagerを無効にしないでください。
DHCPクライアントを停止すると、リースの期限が切れたときにホスト・ルート表が削除されることがあります。また、iSCSI接続へのネットワーク接続が失われると、ブート・ドライブが失われる可能性があります。
ユーザー・アクセス
Linuxインスタンスでは、リモート・ホストからSSHを使用してインスタンスにアクセスできます。Oracle LinuxまたはCentOSプラットフォーム・イメージを使用してインスタンスを作成する場合、ユーザー名はopc
です。Ubuntuプラットフォーム・イメージを使用してインスタンスを作成した場合、ユーザー名はubuntu
です。サインイン後、インスタンスにユーザーを追加できます。
SSHキーを共有したくない場合は、SSH対応の追加ユーザーを作成できます。
Windowsインスタンスでは、リモート・デスクトップ・クライアントを使用してインスタンスにアクセスできます。Windowsプラットフォーム・イメージを使用してインスタンスを作成した場合、ユーザー名はopc
です。サインイン後、インスタンスにユーザーを追加できます。
ユーザー・アクセスの詳細は、インスタンスへのユーザーの追加を参照してください。
NTPサービス
Oracle Cloud Infrastructureでは、完全に管理されたセキュアで可用性の高いNTPサービスが提供されます。これを使用すると、仮想クラウド・ネットワーク(VCN)内からコンピュートおよびデータベース・インスタンスの日時を設定できます。NTPサービスは、Oracle Cloud Infrastructureで使用可能なすべてのプラットフォーム・イメージで、デフォルトで有効になっています。このサービスの詳細は、インスタンスに対するOracle Cloud Infrastructure NTPサービスの構成を参照してください。
フォルト・ドメイン
フォルト・ドメインは、同じ可用性ドメイン内の他のフォルト・ドメインとは異なるハードウェアおよびインフラストラクチャのグループです。各アベイラビリティ・ドメインに3つのフォルト・ドメインがあります。フォルト・ドメインを適切に利用することで、Oracle Cloud Infrastructureで実行されるアプリケーションの可用性を向上させることができます。背景情報については、フォルト・ドメインを参照してください。
アプリケーションのアーキテクチャによって、インスタンスを分離する必要があるか、フォルト・ドメインを使用してインスタンスをグループ化する必要があるかが決まります。
シナリオ1: 高可用性アプリケーション・アーキテクチャ
このシナリオでは、高可用性アプリケーション、たとえば2つのWebサーバーと1つのクラスタ・データベースがあるとします。このシナリオでは、1つのWebサーバーと1つのデータベース・ノードを1つのフォルト・ドメインしにグループ化し、もう一方の組を別のフォルト・ドメインにグループ化する必要があります。この配置では、いずれか1つのフォルト・ドメインに障害が発生しても、アプリケーションが停止することはありません。
シナリオ2: 1つのWebサーバーとデータベース・インスタンスのアーキテクチャ
このシナリオでは、アプリケーション・アーキテクチャの可用性は高くありません。たとえば、1つのWebサーバー・インスタンスと1つのデータベース・インスタンスがあります。このシナリオでは、顧客の停止を最小限に抑えるために、Webサーバーとデータベース・インスタンスの両方を同じフォルト・ドメインに配置する必要があります。この配置では、アプリケーションはその1つのフォルト・ドメインの障害の影響しか受けず、全体的なアプリケーションの可用性が向上します。
顧客管理インスタンスのメンテナンス
Oracle Cloud Infrastructureは、コンピュート・インスタンスの物理インフラストラクチャで定期的なデータ・センター・メンテナンスを実行します。このメンテナンスには、ハードウェアのアップグレードと交換、ホストへの電力供給を停止するメンテナンスの実行などのタスクが含まれます。
Oracle Cloud Infrastructureでは、ライブ移行、スケジュール済メンテナンス、所定の位置での再構築、手動移行など、コンピュート・インスタンスの様々なメンテナンス・アクションがサポートされています。メンテナンス・アクションは、インスタンスが使用するシェイプなどの特性によって異なります。インスタンスに対して実行されるメンテナンス・アクションのタイプによっては、インフラストラクチャ・メンテナンス中にインスタンスで停止時間が発生する場合があります。一部のシェイプでは、停止時間が発生する方法とタイミングを制御できます。詳細は、インフラストラクチャ・メンテナンスを参照してください。
コンピュートのインフラストラクチャ・ヘルス・メトリックを使用して、メンテナンス中のインスタンスのステータスをモニターできます。詳細は、インフラストラクチャ・ヘルス・メトリックを参照してください。