コンピュート・インスタンスのベスト・プラクティス

Oracle Cloud Infrastructure Computeでは、妥協のないパフォーマンス、柔軟性および制御機能を実現する、ベア・メタルおよび仮想マシン(VM)のコンピューティング性能が提供されます。これは、最も要求が厳しいアプリケーションやワークロードを開発してクラウドで実行するために設計された、オラクル社の次世代向けインターネット規模インフラストラクチャを備えています。

使いやすい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)を有効にした後で再起動に失敗しますを参照してください。

システム・レジリエンス

業界全体で行われているハードウェア障害のベスト・プラクティスに従って、ハードウェア障害の発生時にソリューションのレジリエンスを確保してください。ベスト・プラクティスには次のものがあります:
  • 冗長コンピュート・ノードを様々な可用性ドメインに配置するシステムを設計して、フェイルオーバー機能をサポートします。
  • イメージを変更するたびに、システム・ドライブのカスタム・イメージを作成します。
  • 定期的にデータ・ドライブをバックアップするか、予備のドライブに同期します。
ハードウェア障害が発生したとき、これらのプラクティスに従っていた場合は、障害が発生したインスタンスを終了し、カスタム・イメージを起動して新しいインスタンスを作成してから、バックアップ・データを適用できます。

中断されないインスタンスへのアクセス

DHCPクライアントの実行を維持して、常にインスタンスにアクセスできるようにします。DHCPクライアントを手動で停止するか、またはNetworkManagerを無効にする(Linuxインスタンス上のDHCPクライアントが停止される)と、インスタンスはDHCPリースを更新できず、リースの期限が切れたとき(通常24時間以内)にアクセス不可能になります。別の方法を使用してリースの更新を確実に行わないかぎり、NetworkManagerを無効にしないでください。

DHCPクライアントを停止すると、リースの期限が切れたときにホスト・ルート表が削除されることがあります。また、iSCSI接続へのネットワーク接続が失われると、ブート・ドライブが失われる可能性があります。

ユーザー・アクセス

Linuxプラットフォーム・イメージを使用してインスタンスを作成した場合は、SSHを使用して、リモート・ホストからopcユーザーとしてインスタンスにアクセスできます。ログイン後、インスタンスにユーザーを追加できます。

SSHキーを共有したくない場合は、SSH対応の追加ユーザーを作成できます。

Windowsプラットフォーム・イメージを使用してインスタンスを作成した場合は、opcユーザーとしてリモート・デスクトップ・クライアントを使用してインスタンスにアクセスできます。ログイン後、インスタンスにユーザーを追加できます。

ユーザー・アクセスの詳細は、「インスタンスへのユーザーの追加」を参照してください。インスタンスにログインするステップは、インスタンスへの接続を参照してください。

NTPサービス

Oracle Cloud Infrastructureでは、仮想クラウド・ネットワーク(VCN)内からコンピュートおよびデータベース・インスタンスの日時を設定するために使用できる、フルマネージド型で安全かつ可用性の高いNTPサービスが提供されます。NTPサービスは、Oracle Cloud Infrastructureで使用可能なすべてのプラットフォーム・イメージで、デフォルトで有効になっています。このサービスの詳細は、インスタンスに対するOracle Cloud Infrastructure NTPサービスの構成を参照してください。

フォルト・ドメイン

フォルト・ドメインは、同じ可用性ドメイン内の他のフォルト・ドメインと区別するためにハードウェアとインフラストラクチャをグループ化したものです。各可用性ドメインには3つのフォルト・ドメインがあります。フォルト・ドメインを適切に利用することで、Oracle Cloud Infrastructureで実行されるアプリケーションの可用性を向上できます。詳細は、フォルト・ドメインを参照してください。

アプリケーションのアーキテクチャによって、インスタンスを分離する必要があるか、フォルト・ドメインを使用してインスタンスをグループ化する必要があるかが決まります。

シナリオ1: 高可用性アプリケーション・アーキテクチャ

このシナリオでは、高可用性アプリケーション、たとえば2つのWebサーバーと1つのクラスタ・データベースがあるとします。このシナリオでは、1つのWebサーバーと1つのデータベース・ノードを1つのフォルト・ドメインにグループ化し、もう一方のペアを別のフォルト・ドメインにグループ化する必要があります。この配置により、いずれかのフォルト・ドメインに障害が発生しても、アプリケーションが停止することはありません。

シナリオ2: 1つのWebサーバーとデータベース・インスタンスのアーキテクチャ

このシナリオでは、アプリケーション・アーキテクチャの可用性は高くありません。たとえば、1つのWebサーバー・インスタンスと1つのデータベース・インスタンスがあります。このシナリオでは、Webサーバーとデータベース・インスタンスの両方を同じフォルト・ドメインに配置して、顧客の停止を最小限に抑える必要があります。この配置により、アプリケーションが影響を受けるのはその単一のフォルト・ドメインの障害のみになり、全体的なアプリケーションの可用性が向上します。

顧客管理の仮想マシン(VM)メンテナンス

基礎となるインフラストラクチャ・コンポーネントのメンテナンスを行う必要がある場合、デフォルトでOracle Cloud Infrastructureは、次回のメンテナンス・イベントに関する通知を送信します。14から16日後、VMインスタンスは、メンテナンスが必要な物理VMホストから正常なVMホストに、実行中のインスタンスを中断することなく、ライブ移行されます。または、インスタンスを通知なしで自動的にライブ移行することもできます。VMをライブ移行できない場合、インスタンスの再起動移行中に、短い停止時間が発生します。

スケジュールされたメンテナンス・イベントの前に、いつでもインスタンスを事前に再起動(停止して起動)することにより、アプリケーションでメンテナンスの停止時間が発生する方法とタイミングを制御できます。メンテナンス再起動は、通常の再起動とは異なります。メンテナンスのためにインスタンスを再起動すると、メンテナンスが必要な物理VMホストでインスタンスが停止され、正常なVMホストで再起動されます。

スケジュールされた時間よりも前に再起動することをユーザーが選択しない場合、Oracle Cloud Infrastructureがインスタンスを移行してから、計画インフラストラクチャ・メンテナンスの処理に進みます。オプションで、再起動移行後もインスタンスが停止したままになるように構成できます。詳細は、計画メンテナンス中の仮想マシン(VM)のリカバリを参照してください。