diff --git a/modules/ROOT/images/migration-all-phases.png b/modules/ROOT/images/migration-all-phases.png deleted file mode 100644 index 2ea20018..00000000 Binary files a/modules/ROOT/images/migration-all-phases.png and /dev/null differ diff --git a/modules/ROOT/images/migration-all-phases.svg b/modules/ROOT/images/migration-all-phases.svg new file mode 100644 index 00000000..c5188163 --- /dev/null +++ b/modules/ROOT/images/migration-all-phases.svg @@ -0,0 +1,55 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/modules/ROOT/images/migration-phase1ra.png b/modules/ROOT/images/migration-phase1ra.png deleted file mode 100644 index 0a8f367f..00000000 Binary files a/modules/ROOT/images/migration-phase1ra.png and /dev/null differ diff --git a/modules/ROOT/images/migration-phase1ra.svg b/modules/ROOT/images/migration-phase1ra.svg new file mode 100644 index 00000000..5d254ecf --- /dev/null +++ b/modules/ROOT/images/migration-phase1ra.svg @@ -0,0 +1,58 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/modules/ROOT/images/migration-phase2ra.png b/modules/ROOT/images/migration-phase2ra.png deleted file mode 100644 index 6c745d80..00000000 Binary files a/modules/ROOT/images/migration-phase2ra.png and /dev/null differ diff --git a/modules/ROOT/images/migration-phase2ra.svg b/modules/ROOT/images/migration-phase2ra.svg new file mode 100644 index 00000000..b7695fa2 --- /dev/null +++ b/modules/ROOT/images/migration-phase2ra.svg @@ -0,0 +1,64 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/modules/ROOT/images/migration-phase3ra.png b/modules/ROOT/images/migration-phase3ra.png deleted file mode 100644 index 28abc15f..00000000 Binary files a/modules/ROOT/images/migration-phase3ra.png and /dev/null differ diff --git a/modules/ROOT/images/migration-phase3ra.svg b/modules/ROOT/images/migration-phase3ra.svg new file mode 100644 index 00000000..85ba47b0 --- /dev/null +++ b/modules/ROOT/images/migration-phase3ra.svg @@ -0,0 +1,60 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/modules/ROOT/images/migration-phase4ra.svg b/modules/ROOT/images/migration-phase4ra.svg new file mode 100644 index 00000000..4dd02e61 --- /dev/null +++ b/modules/ROOT/images/migration-phase4ra.svg @@ -0,0 +1,58 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/modules/ROOT/images/migration-phase4ra9.png b/modules/ROOT/images/migration-phase4ra9.png deleted file mode 100644 index 842edcf2..00000000 Binary files a/modules/ROOT/images/migration-phase4ra9.png and /dev/null differ diff --git a/modules/ROOT/images/migration-phase5ra.png b/modules/ROOT/images/migration-phase5ra.png deleted file mode 100644 index d57ab2f1..00000000 Binary files a/modules/ROOT/images/migration-phase5ra.png and /dev/null differ diff --git a/modules/ROOT/images/migration-phase5ra.svg b/modules/ROOT/images/migration-phase5ra.svg new file mode 100644 index 00000000..33e856a9 --- /dev/null +++ b/modules/ROOT/images/migration-phase5ra.svg @@ -0,0 +1,47 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/modules/ROOT/images/pre-migration0ra.png b/modules/ROOT/images/pre-migration0ra.png deleted file mode 100644 index 22dc5142..00000000 Binary files a/modules/ROOT/images/pre-migration0ra.png and /dev/null differ diff --git a/modules/ROOT/images/pre-migration0ra.svg b/modules/ROOT/images/pre-migration0ra.svg new file mode 100644 index 00000000..df0a1272 --- /dev/null +++ b/modules/ROOT/images/pre-migration0ra.svg @@ -0,0 +1,42 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/modules/ROOT/pages/change-read-routing.adoc b/modules/ROOT/pages/change-read-routing.adoc index d6768222..170b4216 100644 --- a/modules/ROOT/pages/change-read-routing.adoc +++ b/modules/ROOT/pages/change-read-routing.adoc @@ -8,7 +8,7 @@ This phase routes production read requests to the target cluster exclusively. Make sure all data is present on the target cluster, and it is prepared to handle full-scale production workloads. ==== -image::migration-phase4ra9.png[In migration Phase 4, {product-proxy}'s read routing switches to the target cluster] +image::ROOT:migration-phase4ra.svg[In migration Phase 4, {product-proxy}'s read routing switches to the target cluster] == Prerequisites diff --git a/modules/ROOT/pages/connect-clients-to-proxy.adoc b/modules/ROOT/pages/connect-clients-to-proxy.adoc index f4f31007..823683e6 100644 --- a/modules/ROOT/pages/connect-clients-to-proxy.adoc +++ b/modules/ROOT/pages/connect-clients-to-proxy.adoc @@ -133,7 +133,7 @@ When a client connects to {product-proxy}, the client still provides only one se To forward requests to the other cluster, {product-proxy} uses the credentials defined in `xref:ROOT:deploy-proxy-monitoring.adoc#cluster-and-core-configuration[zdm_proxy_cluster_config.yml]`. .Credential usage by {product-proxy} when authentication is required for both clusters -image::zdm-proxy-credential-usage.png[{product-proxy} credentials usage when authentication is required for both clusters, 550] +image::ROOT:zdm-proxy-credential-usage.png[{product-proxy} credentials usage when authentication is required for both clusters, 550] The credentials that {product-proxy} expects to receive from the client depend on the authentication requirements of the origin and target clusters. Make sure the client passes the correct credentials for your cluster configuration: diff --git a/modules/ROOT/pages/connect-clients-to-target.adoc b/modules/ROOT/pages/connect-clients-to-target.adoc index d4bd855e..514129ab 100644 --- a/modules/ROOT/pages/connect-clients-to-target.adoc +++ b/modules/ROOT/pages/connect-clients-to-target.adoc @@ -6,7 +6,7 @@ Phase 5 is the last phase of the xref:ROOT:introduction.adoc[migration process], In this final phase, you connect your client applications directly and exclusively to the target cluster. This removes the dependency on {product-proxy} and the origin cluster, thereby completing the migration process. -image::migration-phase5ra.png[In Phase 5, your applications no longer use the proxy and, instead, connect directly to the target cluster] +image::ROOT:migration-phase5ra.svg[In Phase 5, your applications no longer use the proxy and, instead, connect directly to the target cluster] The minimum requirements for reconfiguring these connections depend on whether your target cluster is {astra-db} or a generic CQL cluster, such as {cass-reg}, {dse}, or {hcd}. diff --git a/modules/ROOT/pages/deployment-infrastructure.adoc b/modules/ROOT/pages/deployment-infrastructure.adoc index 01018ed9..28228397 100644 --- a/modules/ROOT/pages/deployment-infrastructure.adoc +++ b/modules/ROOT/pages/deployment-infrastructure.adoc @@ -19,7 +19,7 @@ You can deploy {product-proxy} on any cloud provider or on-premises, depending o The following diagram shows a typical deployment with connectivity between client applications, {product-proxy} instances, and clusters: -image::zdm-during-migration3.png[Connectivity between client applications, proxy instances, and clusters] +image::ROOT:zdm-during-migration3.png[Connectivity between client applications, proxy instances, and clusters] The {product-proxy} process is lightweight, requiring only a small amount of resources and no storage to persist its state aside from logs. diff --git a/modules/ROOT/pages/enable-async-dual-reads.adoc b/modules/ROOT/pages/enable-async-dual-reads.adoc index b5763f40..efe1edb5 100644 --- a/modules/ROOT/pages/enable-async-dual-reads.adoc +++ b/modules/ROOT/pages/enable-async-dual-reads.adoc @@ -13,7 +13,7 @@ When you enable _asynchronous dual reads_, {product-proxy} sends asynchronous re At this point in the migration process, the secondary cluster is typically the target cluster. Because this feature is intended to test your target cluster's ability to handle a simulated production workload, there is no reason to run it against the origin cluster that is already capable of handling production workloads. -image:migration-phase3ra.png[In migration Phase 3, enable asynchronous dual reads to send read requests to both clusters] +image::ROOT:migration-phase3ra.svg[In migration Phase 3, enable asynchronous dual reads to send read requests to both clusters] This allows you to assess the target cluster's performance and make any adjustments before permanently switching your workloads to the target cluster. diff --git a/modules/ROOT/pages/introduction.adoc b/modules/ROOT/pages/introduction.adoc index aa40b575..3a31c144 100644 --- a/modules/ROOT/pages/introduction.adoc +++ b/modules/ROOT/pages/introduction.adoc @@ -48,7 +48,7 @@ The _target cluster_ is your new {cass-short}-based environment where you want t From a functional standpoint, before you begin a migration, your client applications perform read/write operations directly with your existing xref:cql:ROOT:index.adoc[CQL]-compatible database, such as {cass}, {dse-short}, {hcd-short}, or {astra-db}. Over the course of the migration, the contact points change to incorporate {product-proxy} and eventually switch to the target database. -image:pre-migration0ra.png[Before the migration begins, your applications connect exclusively to your origin cluster] +image::ROOT:pre-migration0ra.svg[Before the migration begins, your applications connect exclusively to your origin cluster] To plan and prepare for the migration, do the following: @@ -75,7 +75,7 @@ Writes are sent to both the origin and target databases, while reads are execute For more information and instructions, see xref:ROOT:phase1.adoc[Phase 1: Deploy and connect {product-proxy}]. -image:migration-phase1ra.png[In Phase 1, you deploy and connect {product-proxy}] +image::ROOT:migration-phase1ra.svg[In Phase 1, you deploy and connect {product-proxy}] === Phase 2: Migrate data @@ -85,7 +85,7 @@ Then, you thoroughly validate the migrated data, resolving missing and mismatche For more information and instructions, see xref:ROOT:migrate-and-validate-data.adoc[]. -image:migration-phase2ra.png[In Phase 2, you migrate and validate data from the origin cluster to the target cluster] +image::ROOT:migration-phase2ra.svg[In Phase 2, you migrate and validate data from the origin cluster to the target cluster] === Phase 3: Enable asynchronous dual reads @@ -97,7 +97,7 @@ When enabled, {product-proxy} sends asynchronous read requests to the secondary For more information, see xref:ROOT:enable-async-dual-reads.adoc[] and xref:ROOT:components.adoc#how_zdm_proxy_handles_reads_and_writes[How {product-proxy} handles reads and writes]. -image:migration-phase3ra.png[In Phase 3, you test your target cluster's production readiness] +image::ROOT:migration-phase3ra.svg[In Phase 3, you test your target cluster's production readiness] === Phase 4: Route reads to the target database @@ -108,7 +108,7 @@ At this point, the target database becomes the primary database. For more information and instructions, see xref:ROOT:change-read-routing.adoc[]. -image:migration-phase4ra9.png[In Phase 4, you route reads to the target cluster exclusively] +image::ROOT:migration-phase4ra.svg[In Phase 4, you route reads to the target cluster exclusively] === Phase 5: Connect directly to the target database @@ -121,7 +121,7 @@ However, be aware that the origin database is no longer synchronized with the ta For more information, see xref:ROOT:connect-clients-to-target.adoc[]. -image:migration-phase5ra.png[In Phase 5, you connect your client applications directly and exclusively to the target cluster] +image::ROOT:migration-phase5ra.svg[In Phase 5, you connect your client applications directly and exclusively to the target cluster] [#lab] == {product} interactive lab diff --git a/modules/ROOT/pages/metrics.adoc b/modules/ROOT/pages/metrics.adoc index c11d4071..56f53193 100644 --- a/modules/ROOT/pages/metrics.adoc +++ b/modules/ROOT/pages/metrics.adoc @@ -181,7 +181,7 @@ If you already have a Grafana deployment, then you can import the dashboards fro The {product-proxy} metrics dashboard includes proxy level metrics, node level metrics, and asynchronous read requests metrics. -image::zdm-grafana-proxy-dashboard1.png[Grafana dashboard shows three categories of {product-short} metrics for the proxy.] +image::ROOT:zdm-grafana-proxy-dashboard1.png[Grafana dashboard shows three categories of {product-short} metrics for the proxy.] This dashboard can help you identify issues such as the following: @@ -280,7 +280,7 @@ The Go runtime metrics dashboard is used less often than the {product-proxy} met This dashboard can be helpful for troubleshooting {product-proxy} performance issues. It provides metrics for memory usage, Garbage Collection (GC) duration, open FDs (file descriptors), and the number of goroutines. -image::zdm-golang-dashboard.png[Golang metrics dashboard example is shown.] +image::ROOT:zdm-golang-dashboard.png[Golang metrics dashboard example is shown.] Watch for the following problem areas on the Go runtime metrics dashboard: diff --git a/modules/ROOT/pages/migrate-and-validate-data.adoc b/modules/ROOT/pages/migrate-and-validate-data.adoc index d56b54ab..31a5bfe1 100644 --- a/modules/ROOT/pages/migrate-and-validate-data.adoc +++ b/modules/ROOT/pages/migrate-and-validate-data.adoc @@ -5,7 +5,7 @@ In xref:ROOT:phase1.adoc[Phase 1], you set up {product-proxy} to orchestrate liv In Phase 2 of {product}, you migrate data from the origin to the target, and then validate the migrated data. -image::migration-phase2ra.png[In {product-short} Phase 2, you migrate data from the origin cluster to the target cluster] +image::ROOT:migration-phase2ra.svg[In {product-short} Phase 2, you migrate data from the origin cluster to the target cluster] To move and validate data, you can use a dedicated data migration tool, such as {sstable-sideloader}, {cass-migrator}, or {dsbulk-loader}, or your can create your own custom data migration script. diff --git a/modules/ROOT/pages/phase1.adoc b/modules/ROOT/pages/phase1.adoc index 88335137..a5916d3b 100644 --- a/modules/ROOT/pages/phase1.adoc +++ b/modules/ROOT/pages/phase1.adoc @@ -2,7 +2,7 @@ After you plan and prepare for your migration, you can start Phase 1 of the migration process where you deploy and connect {product-proxy}. -image::migration-phase1ra.png[In migration Phase 1, you deploy {product-proxy} instances, and then connect your client applications to the proxies] +image::ROOT:migration-phase1ra.svg[In migration Phase 1, you deploy {product-proxy} instances, and then connect your client applications to the proxies] To complete Phase 1, do the following: diff --git a/modules/ROOT/pages/rollback.adoc b/modules/ROOT/pages/rollback.adoc index 5d7c7712..dbcfa852 100644 --- a/modules/ROOT/pages/rollback.adoc +++ b/modules/ROOT/pages/rollback.adoc @@ -4,7 +4,7 @@ At any point from Phase 1 through Phase 4, if you encounter an unexpected issue After addressing the issue, you can restart the migration from the beginning. -image::migration-all-phases.png[Migration phases from start to finish.] +image::ROOT:migration-all-phases.svg[Migration phases from start to finish.] == Phase 5 is the point of no return diff --git a/modules/ROOT/pages/setup-ansible-playbooks.adoc b/modules/ROOT/pages/setup-ansible-playbooks.adoc index 7961af8b..c24dc3b9 100644 --- a/modules/ROOT/pages/setup-ansible-playbooks.adoc +++ b/modules/ROOT/pages/setup-ansible-playbooks.adoc @@ -10,7 +10,7 @@ After you complete both of these procedures, you will have an active and fully m This utility prompts you for a few configuration values, with helpful embedded explanations and error handling, and then it creates and prepares the Ansible Control Host container automatically. From this container, you will configure and run the {product-automation} Ansible playbooks. -image::docker-container-and-zdm-utility.png[{product-proxy} connections from Docker container created by {product-utility}] +image::ROOT:docker-container-and-zdm-utility.png[{product-proxy} connections from Docker container created by {product-utility}] For more information about {product-utility} and {product-automation}, see xref:ROOT:components.adoc[]. @@ -222,7 +222,7 @@ The following example uses the same IP address as the Ansible Control Host machi . Review the configuration summary printed to the terminal by {product-utility}. At this point, {product-utility} has created the Ansible inventory file name `zdm_ansible_inventory` (unless you provided your own custom file), and it has written the {product-utility} configuration to `ansible_container_init_config`. + -image::zdm-go-utility-results3.png[A summary of the configuration provided is displayed in the terminal] +image::ROOT:zdm-go-utility-results3.png[A summary of the configuration provided is displayed in the terminal] . Type kbd:[Y] to continue and trigger the following processes: + @@ -231,7 +231,7 @@ image::zdm-go-utility-results3.png[A summary of the configuration provided is di .. {product-utility} prints a message when the Ansible container is fully initialized and ready to use. + -image::zdm-go-utility-success3.png[Ansible Docker container success messages] +image::ROOT:zdm-go-utility-success3.png[Ansible Docker container success messages] == Next steps