この手順は、次の使用ケースに使用します。
- インスタンスの展開後にHSNをプロビジョニングする場合。この使用ケースでは、自動スケーリング権限を変更する必要はない。
- Teradata Vantage on AWS (DIY) 5.02より前のインスタンスを展開し、ソフトウェア アップグレードを実行していて、HSNをプロビジョニングする場合。この使用ケースでは、この手順の一部として新しい自動スケーリング グループが作成されるため、IAM管理者に次の権限を付与するように依頼する。
- autoscaling:CreateAutoScalingGroup
- autoscaling:CreateLaunchConfiguration
- autoscaling:DeleteLaunchConfiguration
展開後にHSNをプロビジョニングすると、障害が発生するリスクが高くなります。リソースの問題により、AWSがリソースをプロビジョニングできない場合があります。AWSは、成功するまでプロビジョニングを自動的に再試行します。
- データベース ノードから、HSNが現在構成されているかどうかを確認します。
# tdc-hot-standby --hsn-status
- 最大2つのHSNをプロビジョニングします。
# tdc-hot-standby -m nここで、nはプロビジョニングするHSNの数です。 - HSNが起動および構成されたときにステータスを取得します。
# tdc-hot-standby --hsn-status
- イメージが古くなっているか、HSNのインスタンス タイプがノードのインスタンス タイプと異なる場合は、HSNを更新します。
# tdc-hot-standby -u
自動スケーリング グループはそれに応じて更新されます。 - (オプション)HSNが最新であることを確認します。
# tdc-hot-standby --hsn-status
HSNをプロビジョニングした後、データベースを停止して再起動する必要はありません。
- リソースの問題によりAWSがHSNのリソースをプロビジョニングできず、プロセスを取り消す場合は、AWSプロビジョニング プロセスを停止します。
# tdc-hot-standby -m 0
HSNがプロビジョニングされるまで関連するコストは発生しないため、このプロセスを取り消さないでおくことを推奨します。
EC2コンソールからプロビジョニング プロセスをモニターできます。
- HSNは、展開時にすべてstack name-hsnという名前になる。例えば、スタック名がmydbsの場合、HSNの名前はmydbs-hsnになる。
- タグタブから、HSNのキーとステータスを表わす値でHSNを識別できる。ステータスは最初にconfiguringと表示される。
- HSNを使用する準備ができると、ステータスがレディに変わる。
- ノードに障害が発生すると、HSNは障害が発生したノードに接続し、HSNのステータスがIn-Useに変わる。
- 別のHSNが自動的に展開され、使用されていたHSNが置き換えられる。これはアイドル状態になり、別のノードに障害が発生するまでサービスを開始しない。