Getting started
Selecting a license
Navigate to the Admin tab, then select the License section on the left side. The UI will show restrictions for each license tier, the currently selected tier (DCT Enterprise, in this example), and the current engine counts.
Installing DCT 23.0.0 and beyond
DCT licenses will be defaulted to DCT Core at the time of installation. Once installed, administrators will be able to update their license by accessing the License section (under the Admin tab) and selecting DCT for Self Service or Enterprise.
Upgrading from DCT 22.0.0 and below
Users looking to upgrade to DCT 23.0.0 or later versions will now have to select their license post-upgrade. Once the upgrade is complete, DCT will default to DCT Enterprise to assure no functionality is lost. Users entitled to a lower tier of DCT must perform a license downgrade, which can be performed in the License section (under the Admin tab)
Downgrades will be blocked if prerequisites (e.g., DCT has more than the number of allowed engine connections for that license tier) are not met. This is to prevent loss of data as disconnecting an engine will remove the metadata associated with that engine.
Changing licenses
Upgrade the license tier via the UI (always possible).
Downgrading the license tier via the UI (only possible if the engine count restriction is satisfied for the target tier).
Planning your deployment
Data Control Tower (DCT) represents a Delphix-wide control plane. It simultaneously powers data governance, automation, and compliance workflows to enable the efficient operation of a broad, complex Delphix deployment at scale. In order to deliver scalability, service-level performance tuning, and robust resiliency, DCT leverages container technology to deliver a bespoke experience for administrative teams based on their own internal guidelines.
For Kubernetes, OpenShift, and docker-compose
Before starting a DCT deployment, please contact your enterprise IT organization to determine what container platforms, configurations, and policies apply for container-hosted applications. It is helpful to include a container administrator as part of the DCT install process.
For Appliance (OVA image)
The above note is not applicable. If you deploy via OVA image, you will need to choose a hypervisor with similar configurations found here.
Container platform support
Data Control Tower (DCT) supports deployment methods for Kubernetes, OpenShift, and via virtual appliance (OVA image). If you do not see a platform of choice, please reach out to your account team for more details.
DCT is designed to run and is supported on any Certified Kubernetes platform that supports Helm. The product is also OCI-compliant and may use any container runtime within a certified Kubernetes platform that implements the OCI Runtime Specification including CRI-O, Docker, and Podman.
Delphix regularly tests against a range of popular Kubernetes platforms with the goal of covering a representative sample of implementations. The following Kubernetes platforms have been explicitly tested by Delphix and are recommended for use: MicroK8s, AWS EKS, Azure AKS, and OpenShift on VMWare vSphere.
Kubernetes
DCT currently supports all popular deployment models of Kubernetes as long as the service runs a minimum of Kubernetes 1.25 and above. This includes Amazon Elastic Kubernetes Service (Amazon EKS), Azure Kubernetes Service (AKS), and beyond.
OpenShift
DCT also supports all popular deployment models of Openshift as long as the service runs a minimum version of 4.12 or above. This includes Red Hat OpenShift on IBM Cloud and any other cloud provider’s service.
Virtual appliance (OVA image)
DCT now offers a virtual machine deployment method (distributed as a closed appliance OVA image) similar to standard Continuous Data and Compliance engine deployments.
Data Control Tower deployment architecture
Whether an organization wants to deploy a Data Control Tower (DCT) per business unit (organizational silos), per network (datacenter-specific DCT), or globally (the most common option), DCT can adapt to many deployment scenarios.
Delphix recommends to deploy a single, global DCT for all Delphix Engines, for the purposes of achieving a single control plane and data governance solution.
DCT-based communication is lightweight, requiring simple commands or a small telemetry payload to facilitate most workflows. The below graphic demonstrates this style of communication:
DCT simply logs into the engines as a user would and leverages engine APIs to perform commands or extract metadata.
DCT requires HTTP/HTTPS to facilitate communication with engines and requires ports 80/443 to reach engines in other networks.
DCT does not directly interface with business-critical databases, it will only communicate with engines to perform operations and inquire about system statuses. The Delphix Engine, which is generally co-located with your data, does all the heavy lifting.
Plan your tagging strategy
DCT tags serve as the Delphix-wide business metadata system. These Key:Value pairs can be applied to any object and used for search and filter in virtually every DCT workflow, from automation to administration, all the way to access control.
It is paramount to develop a tagging strategy prior to deployment in order to develop a scalable metadata solution.
Some examples of popular tagging strategies:
Theme | Sub-topics | Tag (Key:Value) example |
---|---|---|
Owner | Application, Business, Project, Team (scrum, QA,…) | (Owner: Finance App), (Owner: AppTeam Alpha), (Owner: John Doe), … |
Application | (Application: Alpha) | |
Environment | (Environment: Non Production) | |
Location | Data Center, Region, Name, Cloud | (Geo: West Coast), (Data Center: Azure WC), … |
In addition to designing which tags to implement, please consider who will have access to creating tags (i.e. developer vs admin-only, etc.), which will impact how teams are able to collaborate with one another.
Also, Delphix recommends that the DCT administrative team creates Delphix-wide documentation on these tagging standards to reduce the risk of deviation.
Plan your Access Control strategy
DCT implements a model found in other types of software called Attribute Based Access Control (ABAC). This model is incredibly flexible, but requires detailed configurations to perfect your use cases. In DCT’s model, there are four entity types (defined below). Familiarize with each entity, as they are the foundational blocks of DCT’s ABAC model.
Entity | Description | Managed by |
Accounts | A single or shared user who can authenticate with DCT (UI or API). | Create manually or via Identity Provider (IdP), such as SSO or LDAP. Accounts are independent of Delphix Engines. |
Access Groups | A collection of accounts that share one or more characteristics, such as a Team or Permission set. Equivalent to an Active Directory group. | Manually created. Populated manually or via the |
Roles and Permissions | The collection of read, write, and delete permissions forms a reusable, named role. | Some roles are provided out of the box, but Admins can build their own from the available permissions. Individual permissions are immutable. |
Objects | Units, such as VDBs, Bookmarks, and Environments, that are managed across the Delphix Platform. | Automatically identified by DCT from the connected engines. Assigned to Roles via various models. The CD and CC Engines supply these objects. |
Each entity is linked to another through manual or automated assignment. A manual (or direct) assignment is a good approach for early implementations, however, that can be challenging to maintain as teams grow. As an alternative, tagging is recommended to perform automatic assignments based on your custom configuration. The below diagram shows how each entity is linked together. The directions below start with Accounts creation to Access Groups with Role assignments, and finish with Object mappings.
Understanding your team structure is imperative to identify the best access model. Usually, organizations have existing groupings defined in their Identify Provider (IdP). These groups are typically organized in one of two ways:
A team dedicated towards a central goal (such as a Product Development team).
A group of individuals with similar permissions (such as Security Administrators).
Understanding the purpose of each group should be a guide in how the Roles and Permissions are designed. For example, the Alpha product development team might have full permission to manage existing VDBs and create new bookmarks for their team’s “Alpha” objects. On the other hand, Security Admins might have sweeping read and disable access across the entire platform to ensure compliancy. Iterating through each Access Group and designing custom, but re-useable roles, based on the Principle of Least Privilege, will produce a streamlined rollout.