Here are some scenarios you may encounter at work:
Self-built ES clusters need to be smoothly migrated to the xx cloud
Migrate the ES cluster from the xx cloud to the self-built data center
ES clusters are upgraded across versions while retaining the fallback capability
These scenarios often have one thing in common:The migration process should ensure minimal downtime for the business.
Luckily, in all three scenarios, we can use the Extreme Gateway to help us with a smoother migration or upgrade. Let's take migrating an ES cluster to the cloud as an example to describe the entire process.
Self-built version: 54.2
Cloud version: 56.16
The latest version of the Gateway and Console is recommended.
By sending the application-side traffic through the gateway, the request is synchronized to the self-built ES, the gateway records all write requests, and ensures that the request is replayed in order on the xx cloud ES, and all kinds of faults of the clusters on both sides are properly handled, so as to achieve transparent cluster dual write and achieve secure and seamless data migration.
If the business side and the extreme gateway are still on the enterprise intranet, you can use the Layer 4 floating IP of the extreme gateway to ensure the high availability of the gateway.
To ensure seamless and transparent data migration, the gateway is used to perform dual writes.
System tuning. Install the Infini Gateway
Modify the gateway configuration.
In this gateway dual-write configuration, the default gateway loads the configuration file gatewayyml 。If you want to specify a different profile, use the -config option.
There is a lot of content in the configuration file, and only the necessary parts are shown below.
#primary primary_endpoint: primary_username: elastic primary_password: password primary_max_qps_per_node: 10000 primary_max_bytes_per_node: 104857600 #100mb/s primary_max_connection_per_node: 200 primary_discovery_enabled: false primary_discovery_refresh_enabled: false #backup backup_endpoint: backup_username: admin backup_password: admin backup_max_qps_per_node: 10000 backup_max_bytes_per_node: 104857600 #100mb/s backup_max_connection_per_node: 200 backup_discovery_enabled: false backup_discovery_refresh_enabled: falseprimary_endpoint: Configure the address and port of the primary cluster.
primary_username、primary_password: Access the user information of the primary cluster.
backup_endpoint: Configure the IP address and port of the standby cluster.
backup_username、backup_password: Access the user information of the secondary cluster.
Start the gateway. Start the gateway and specify the configuration you just created, as follows:
./gateway-linux-amd64 -config replication_via-disk.yml.yml
To facilitate quick switching between multiple clusters, manage gateway consumption tasks and view queues. Use the Infini Console to manage it.
*Installation. Start the service.
./console-linux-amd64 -service install
./console-linux-amd64 -service start
Sign up for resources. Register both the ES cluster and the extreme gateway in the console.
Register an ES cluster: You can switch clusters and run commands. In addition to the old and new clusters, the gateway is also registered here once to facilitate the verification of gateway functionality.
Register gateway: Manage gateway tasks and queues.
To verify that the gateway is working, let's do a quick job with the Infini console.
First, create an index through the gateway interface and write a document, as follows:
View 54.2 The data situation of the cluster is as follows:
Look at Cluster 56.16 The data situation is as follows:
If the data is consistent, the gateway configuration is normal and the verification is complete.
Because we need to append incremental data only after the full data migration is complete, we should suspend the consumption of incremental data until the full data migration is complete. Modify the pipeline in the gateway configurationconsume-queue_backup-bulk_request_ingestion-to-backupparametersauto_startforfalse, which indicates that the task is not automatically started, and the following describes how to configure the task
After the configuration is modified, the gateway needs to be restarted.
Since the gateway has been registered before, after the full migration is completed, you can start and stop subsequent tasks through the task management in the background, as follows:
Next, switch the traffic that is normally written to the gateway, that is, you need to point to ES 54.The address of 2 points to the address of the gateway, if 54.2 The cluster has authentication enabled, and the business side ** also needs to pass the identity information, and 54.2 The previous usage remains the same.
After the traffic is switched to the gateway, the user's requests are still accessed to the self-managed cluster in synchronous mode, and the requests recorded by the gateway are recorded to MQ in order, but the consumption is suspended.
If the SDK of the ES used by the business supports SNIFF, and the business has SNIFF enabled, then SNIFF should be turned off to prevent the business from directly connecting to the ES node of the backend through SNIFF, and all traffic should now only be accessed through the gateway.
After the traffic is migrated to the gateway, we start to fully migrate the data from the self-built Elasticsearch cluster to the xx cloud Elasticsearch cluster.
There are many ways to fully migrate existing data
Restore data by snapshot.
Use the Infini Console for data migration.
In the process of full import, there may be incremental modifications to the data, but these requests have been fully recorded, and we only need to enable the consumption task of the gateway to apply the backlog of requests to the ES cluster in the cloud.
An example operation is as follows:
You can determine whether the incremental data is completed by observing whether the queue is consumed, as follows:
Since there may be a lot of data within the cluster, we need to perform a complete comparison to ensure the integrity of the data, which can be done through the data comparison tool of the Infini Console.
If the data of the two clusters is completely consistent after verification, you can switch the program to the new cluster, or swap the primary/standby configuration of the gateway and still write to the two clusters, first to the cloud cluster and then to the self-built cluster.
Dual-cluster** runs for a period of time, and after the service is fully verified, the old cluster can be safely taken offline, and if you encounter problems, you can also switch back to the old cluster at any time.
During the migration process, the two clusters are decoupled through the gateway, and the versions of the two clusters can be different, and the versions of the two clusters can be seamlessly upgraded during the migration process.
Workflow diagram