DOC-5653 Update ZDM diagrams

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
 

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:

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}.
 

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.
 

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.
 

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

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:
 

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.
 

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:
 

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
 

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