サービスを構成するときは、次の推奨事項を考慮してください:
ストレージ・デバイスをプロビジョニングするのではなく、アナリティク問合せ処理でストレージ・デバイスに過負荷がかからないように、ZFSSA上で構成され実行されているカスタム・アナリティクス・レポートの量を制限します。 これにより、ZFSSAの最高のパフォーマンスが保証されます。
Oracleにインストールされたコンピュート・インスタンスで提供されるデフォルトのaggr1またはaggr1_vnic1ネットワーク・データリンクおよびインタフェースを変更または破棄しないでください。 これらのデバイスは、インスタンスにアクセスできる唯一の初期手段であり、変更または削除するとコンピューティング・インスタンスにアクセスできなくなる可能性があります。そのため、Oracleにサービス・リクエスト(SR)を開いてネットワーク構成を回復する必要があります。
Oracleの推奨事項がない場合は、/etc/systemの設定を変更しないでください。 各インスタンスは、現在のベスト・プラクティスに基づいてZFSアーク・キャッシュを制限するように事前構成されています。
プライマリ・インタフェース(データリンクまたは最初のVNICインタフェース)を削除したり、インスタンスが配信されたIPアドレスを変更したりしないでください。 これにより、インスタンスへの接続が失われる危険性があります。接続をリストアするためにサービス・リクエスト(SR)を提出する必要があります。
shutdownコマンド、init 0、1、2、3、4、5、Sなどを使用しないでください。また、システムがマルチユーザー・モードで起動できないような操作をしないでください。 これにより、コンソールへのアクセスがないため、インスタンスにアクセスできなくなります。 カーネル・ゾーンまたはレガシー・サポート・ゾーンを使用している場合は、オペレーティング・システムに必要なCPUリソースとメモリー・リソースも考慮に入れてください。
インスタンスが使用できない場合(または使用できなくなった場合)、Oracle Supportを使用してサービス・リクエスト(SR)を送信してください。 SRを開く方法については、「ステップ5: サービス・リクエストを開く方法について学ぶ」と「Cloud Supportヘルプ: サービス・リクエスト」を参照してください。
サービスごとに各インスタンスのバックアップを作成することを強くお勧めします。 インスタンスを再構築する必要がある致命的なエラーの場合、インスタンスは最初の状態に再作成されます。これは、最初にサービスにアクセスしたときと同じ状態です。 インスタンスへの変更はすべて失われます。
ローカル・ストレージを使用する代わりに、ZFSSA iSCSI LUNストレージ・ボリュームを使用することをお勧めします。
システムが配信されるデフォルトのパスワードを変更します。
Oracle SPARC Model 300 Serviceインスタンスがワークロードの復元力のあるプラットフォームを提供するようにするには、最新のセキュリティ・パッチがインスタンスとゾーンで実行されているオペレーティング・システムに適用されていることを確認してください。 さらに、インスタンスにアプリケーションをデプロイする前に、オペレーティング・システムのセキュリティ構成を確認し、セキュリティ・ポリシーおよび標準に準拠していることを確認してください。 セキュリティおよびパッチ関連のガイドラインについては、ご使用のオペレーティング・システムの資料を参照してください(たとえば、「CVEアップデートの管理: Oracle Solaris 11.3セキュリティ・コンプライアンス・ガイド」および「Oracle Solaris 11セキュリティとセキュリティ強化のガイドライン」を参照)。
ゾーンとストレージ・ボリュームを作成するときは、オブジェクトの名前を慎重に選択します。 後でオブジェクトの主要な特性をすばやく特定するのに役立つ名前を選択します。 たとえば、起動可能なストレージ・ボリュームを作成する場合は、オペレーティング・システム名とイメージ・ディスク・サイズをストレージ・ボリュームの名前に含めることを検討してください。
ゾーンのサイズを構成する際には、インスタンスにデプロイする予定のアプリケーションの性質、アプリケーションを使用する予定のユーザー数、将来的にどのように負荷をスケールするかを検討してください。 カーネル・ゾーンまたはブランド・ゾーンを使用している場合は、オペレーティング・システムに必要なCPUリソースとメモリー・リソースも考慮してください。
ロード中の断続的なスパイクに対して十分なバッファを使用して、ワークロードの要件を満たすゾーンを構成します。 インスタンスに適したシェイプが不明な場合は、小規模から始めて、代表的なワークロードを試してから、ゾーン構成を決定してください。 この方法は、リソースの割り当てとパフォーマンスの最適なトレードオフを達成するのに役立ちます。
Oracle Solarisインスタンスを作成する場合は、インスタンスにアクセスするユーザー数を決定し、各ユーザーの個別のSSHキー・ペアを計画してください。
あなたのSSH鍵を安全に保つ。 従業員が退職したり、他の部署に移ったりするときに、鍵が失われたり盗難されたりしないように、ポリシーを立てる。 秘密鍵を失った場合、インスタンスにアクセスすることはできません。 ビジネス継続性のために、最低2人のITシステム管理者のSSHキーがインスタンスに追加されていることを確認してください。
各ZFSSAヘッドが提供するボリューム(iSCSI LUN)の数を500に制限します。 これは厳しい制限ではありませんが、そうすることで、ZFSSAヘッドの1つまたは他の障害が発生した場合のユーザーによる長いフェイルオーバー時間が残り、残りのヘッドによる引き継ぎ時間が制限されます。 これにより、故障したヘッドから残りのヘッドに移行中のストレージにアクセスしようとすると、ストレージの待機時間が長くなって意図しないアプリケーションの障害が発生するのを防ぐことができます。
ストレージ・ボリュームはiSCSI LUNです。 通常、インスタンスに最初にマウントし、専用または共有ストレージ・ボリュームが必要なゾーンにマッピングする必要があります。
使用するメディエータの実装をOpenSSHに切り替えることで、Oracle Solaris 11.3上で動作するアプリケーションの転送速度、したがってパフォーマンスを向上させることができます。 Oracle Solaris 11.3でOpenSSHを使用する方法の詳細については、「Oracle Solaris 11.3でのセキュア・シェル・アクセスの管理でのSecure ShellのOpenSSH実装の使用方法」を参照してください。