創業以来、クラウドベースの環境への移行が増えています。結局のところ、クラウドコンピューティングは、ビジネス、特にビッグデータを扱うビジネスに多くのメリットをもたらすことができます。
ただし、需要が増えるとコストも増えるため、毎月のクラウド費用が高すぎる状況に陥り、すぐにマイナスがクラウドでの運用のメリットを上回ります。または、セキュリティまたはコンプライアンスの要件があり、システムをより直接的に制御する必要がある場合もあります。これにより、最終的にはオンプレミス環境に移行できるようになる可能性があります。
AWSは、最適化のための可視性と制御を備えながら、クラウドでシステムを実行するための監視および管理ツールを提供します。ただし、オンプレミスソリューションの準備ができたら、データを移行し、システムを適切に管理するためのすべてのツールを再作成するのは難しい場合があります。
このブログでは、システムをAWSからオンプレミスのデータセンターに移行する方法と、ClusterControlがプロセスの合理化にどのように役立つかについて説明します。
始める前に、AmazonCloudとClusterControlに関するいくつかの基本的な概念について説明しましょう。
AWS
アマゾンウェブサービス（AWS）は、多数の独立したサービスと半独立したサービスで構成されるサービスとしてのインフラストラクチャプラットフォームです。サービスとしてのインフラストラクチャプラットフォームの目的は、以前はハイエンドサーバー、ネットワークルーター、スイッチなどの資本集約的なインフラストラクチャコンポーネントの購入が必要だったサービスを、コモディティベースで提供することです。独自のデータセンター。
RDS
Amazon Relational Database Service（RDS）を使用すると、クラウドでのリレーショナルデータベースのセットアップ、操作、スケーリングが簡単になります。ハードウェアのプロビジョニング、データベースのセットアップ、パッチ適用、バックアップなどの時間のかかる管理タスクを自動化しながら、コスト効率が高くサイズ変更可能な容量を提供します。
Amazon RDSは、いくつかのデータベースインスタンスタイプで利用でき、Amazon Aurora、PostgreSQL、MySQL、MariaDB、Oracle Database、SQLServerなどの6つの使い慣れたデータベース管理システムから選択できます。
>EC2
Amazon Elastic Compute Cloud（EC2）は、クラウドで安全でサイズ変更可能なコンピューティング容量を提供するサービスです。開発者がウェブスケールのクラウドコンピューティングを簡単に行えるように設計されています。
Amazon EC2のシンプルなウェブインターフェースを使用すると、最小限の摩擦で容量を取得して設定できます。コンピューティングリソースを完全に制御し、Amazonの実績のあるコンピューティング環境で実行できるようにします。
ClusterControl
ClusterControlは、オープンソースデータベース用の包括的な管理システムであり、展開、管理機能、およびヘルスとパフォーマンスの監視を1つのガラス板から自動化します。
ClusterControlは、あらゆる環境でのさまざまなデータベーステクノロジーの展開、管理、監視、およびスケーリングをサポートします。
前述のように、AWSからオンプレミス環境に移行する最も一般的な理由は、コスト、セキュリティ、コンプライアンス、またはローカルアプリケーションの実行です。 AWSでは、インフラストラクチャの内部で何が起こっているのかわかりません。あなたはすべてが機能しているかどうかだけを知っています。パフォーマンスの低下や異常が発生した場合、唯一の解決策はAmazonサポートに連絡することです。
AWSには、このブログに関連するEC2とRDSの2つの異なる製品があります。
これらの主な違いは、EC2ではサーバーへのSSHアクセスがあり、データベースを自分で管理する必要があることです。 RDSはホストされたデータベースサービスであり、データベースインスタンスにのみアクセスできます。
RDSでは、SSHアクセスがないため、ダンプを作成して新しいサーバーにインポートするか、レプリケーションを構成してレプリカを新しいプライマリにプロモートする必要があります。どちらのオプションでも、プロセスは手動です。このプロセスを改善するためにロードバランサーを追加することもできます。このタスクについては、パート1とパート2のブログで取り上げました。
では、EC2からの移行に焦点を当てましょう。
この例では、MySQLをAWSEC2からオンプレミスのデータセンターに移行する方法を見てみましょう。 MySQLレプリケーション環境を使用しますが、これらの手順はPostgreSQLなどの他のテクノロジーでも機能するはずです。
メインのMySQLデータベースがEC2インスタンスで実行されていると想定します。オンプレミスのデータセンターでは、ClusterControlがインストールされており、移行先の新しいデータベースサーバーがあることも前提としています。
AWS管理コンソールでは、EC2に次のようなものが必要です。インスタンスセクション：
まず、EC2で実行されている現在のプライマリノードをインポートする必要がありますClusterControlに。このインポートプロセスでは、EC2インスタンスに関連付けられているセキュリティグループを編集して、ポート3306を開く必要があります。
この後、ClusterControl内で[インポート]セクションに移動します：
>
そこで、データベーステクノロジー、この例ではMySQLレプリケーションを選択できます。また、SSH経由でサーバーに接続するには、ユーザー、キーまたはパスワード、およびポートを指定する必要があります。また、新しいクラスターの名前も指定する必要があります。
SSHアクセス情報を設定した後、次のようなデータベース情報を定義する必要があります。データベース管理者の資格情報、ポート、およびbasedir。また、新しいクラスターに対してClusterControlノードの自動回復機能とクラスターの自動回復機能を有効にすることもできます。
次に、IPアドレスまたはホスト名を使用してサーバーを追加し、[インポート]を押す必要があります。
完了したら、インポートジョブのステータスを監視できます。 ClusterControlアクティビティモニター。
タスクが完了すると、データベースノードがメインに表示されます。 ClusterControl画面：
現在のマスターデータベースでbinlog生成を有効にしてください。
これで、現在のプライマリデータベースから新しいレプリカとして将来の新しいプライマリノードを追加できます。これを行うには、ClusterControl-> Select Cluster-> Cluster Actions-> AddReplicationSlaveに移動します。
ここで、新しいレプリカのホスト名またはIPアドレスを追加する必要がありますサーバー、およびClusterControlにソフトウェアをインストールさせたい場合。
AWSからオンプレミスサーバーのポート3306および9999に接続できることを確認してください。
ClusterControlは、プライマリのホットバックアップを作成し、それをレプリカにストリーミングして、そこで復元することにより、データを使用してレプリカをステージングします。復元されると、レプリカノードはプライマリノードに接続されるため、イベントに追いついて同期することができます。ある程度の負荷で実行されている大規模なデータベースの場合、プライマリノードでのこの操作の余分な負荷を回避したい場合があることに注意してください。その場合、最初に既存のバックアップからレプリカノードを構築し、次にレプリカを接続して、プライマリノードに追いつくことができます。
このタスクの後、次のようになります。
ClusterControlトポロジセクションでトポロジを確認することもできます。
>
次に、レプリカをプライマリにプロモートする必要があります（ClusterControl-> Selectクラスター->ノードアクション->スレーブのプロモート）、アプリケーションのエンドポイントを変更します。
このトポロジを改善するために、ロードバランサーを追加してトラフィックを管理できますアプリケーションサーバーからデータベースへ。ロードバランサーを使用する場合、移行中にアプリケーションからエンドポイントを変更する必要はありません。ロードバランサーは、透過的な方法でプライマリノードを変更します。
このタスクを実行する方法はたくさんあり、次のことができるはずです。インフラストラクチャ、セキュリティなどに応じて、このような戦略を環境に採用します。
セキュリティ上の理由から、AWSとオンプレミス環境の間でVPNの使用を検討する必要があります。
Galera Clusterのようなマルチマスタートポロジの場合、オンプレミスで必要なノードを追加するだけで済みますが、レイテンシーには注意してください。たとえば、さまざまなガレラセグメントを使用して、ネットワークの使用量を減らすことができます。
最後に、AWSを離れて独自の環境を使い始める場合に考慮すべき、いくつかの考慮事項があります。
- 監視：監視システムを使用することを忘れないでください。システムで何が起こっているかを常に知る必要があります。
- ディザスタリカバリ戦略：優れたDRPを検討する必要があります。一般に、情報は、プライマリ、レプリカ、バックアップの3つの異なる物理的な場所にある必要があります。
- 高可用性：現在、ほとんどの実稼働環境では高可用性が必須であるため、インフラストラクチャに応じて最適な高可用性ソリューションを検討する必要があります。
- スケーリング：将来必要に応じて、または特定のイベントに合わせてスケーリングできるようにする必要があります。
- ロールバック：AWSからオンプレミス環境に移行する場合は、（他のタイプの移行と同様に）問題が発生する可能性があるため、ロールバック計画を立てる必要があります。
- AWSとオンプレミスでインスタンスが実行されている、ある種のハイブリッド環境を求めているとします。その場合、ClusterControlは、可用性、バックアップ、スケーリングなどの監視、管理に最適です。試してみてください！
クラウドでの運用が最適ではない場合があり、オンプレミスソリューションに移行する必要がある場合があります。このブログが、MySQLベースのデータをAWSからオンプレミスデータセンターに移行する方法と、ClusterControlがシステムを適切に管理するために必要なツールを提供する方法に関する役立つ情報を提供してくれることを願っています。
移行が正常に完了したら、予測アラートなどの予防的な戦略を使用して監視システムをレベルアップします。詳細については、ClusterControlを使用したデータベース監視に関する最近更新された投稿を確認してください。
データベース管理のヒントとベストプラクティスの最新情報については、ブログ、RSSフィードを購読し、LinkedInとTwitterでフォローしてください。