Challenge
The domain architecture in PowerCenter simplifies the administration of disparate PowerCenter services across the enterprise as well as the maintenance of security throughout PowerCenter. It allows for the grouping of previously separately administered application services and nodes into logically-grouped folders within the domain, based on administrative ownership. It is vital when installing or upgrading PowerCenter, that the Application Administrator understand the terminology and architecture surrounding the Domain Configuration in order to effectively administer, upgrade, deploy, and maintain PowerCenter Services throughout the enterprise.
Description
The domain architecture allows PowerCenter to provide a service-oriented architecture where you can specify which services are running on which node or physical machine from one central location. The components in the domain are ‘aware’ of each other’s presence and continually monitor one another via ‘heartbeats’. The various services within the domain can move from one physical machine to another without any interruption to the PowerCenter environment. As long as clients can connect to the domain, the domain can route their needs to the appropriate physical machine.
From a monitoring perspective, the domain provides the ability to monitor all services in the domain as well as control security from a central location. You no longer have to log into and ping multiple machines in a robust PowerCenter environment – instead a single screen displays the current availability state of all services.
For more details on the individual components and detailed configuration of a domain, refer to the PowerCenter Administrator Guide.
Key Domain Components
There are several key domain components to consider during installation and setup:
- Master Gateway – The node designated as the master gateway or domain controller is the main ’entry point’ to the domain. This server or set of servers should be your most reliable and available machine in the architecture. It is the first point of entry for all clients wishing to connect to one of the PowerCenter services. If the master gateway is unavailable, the entire domain is unavailable. You may designate more than one node to run the gateway service. One gateway is always the master or primary, but by having the gateway services running on more than one node in a multimode configuration, your domain can continue to function if the master gateway is no longer available. In a high-availability environment, it is critical to have one or more nodes running the gateway service as a backup to the master gateway.
- Shared File System – The PowerCenter domain architecture provides centralized logging capability and; when high-availability is enabled, a highly available environment with automatic fail-over of workflows and sessions. In order to achieve this, the base PowerCenter server file directories must reside on a file system that is accessible by all nodes in the domain. When PowerCenter is initially installed, this directory is called infa_shared and is located under the server directory of the PowerCenter installation. It includes logs and checkpoint information that is shared among nodes of the domain. Ideally, this file system is both high-performance and highly available.
- Domain Metadata – As of PowerCenter 8, a store of metadata exists to hold all of the configuration settings for the domain. This domain repository is separate from the one or more PowerCenter repositories in a domain. Instead, it is a handful of tables that replace the older version 7.xpmserver.cfg, pmrep.cfg and other PowerCenter configuration information. As of PowerCenter 8.5, all PowerCenter security is also maintained here. Upon installation you will be prompted for the RDBMS location for the domain repository. This information should be treated like a PowerCenter repository, with regularly-scheduled backups and a disaster recovery plan. Without this metadata, a domain is unable to function. The RDBMS user provided to PowerCenter requires permissions to create and drop tables, as well as insert, update, and delete records. Ideally, if you are going to be grouping multiple independent nodes within this domain, the domain configuration database should reside on a separate and independent server so as to eliminate the single point of failure if the node hosting the domain configuration database fails.
Domain Architecture
Just as in other PowerCenter architectures, the premise of the architecture is to maintain flexibility and scalability across the environment. There is no single best way to deploy the architecture. Rather, each environment should be assessed for external factors and then PowerCenter should be configured appropriately to function best in that particular environment. The advantage of the service-oriented architecture is that components in the architecture (i.e., repository services, integration services, and others) can be moved among nodes without needing to make changes to the mappings or workflows. Starting in PowerCenter 8.5, all reporting components of PowerCenter (Data Analyzer and Metadata Manager) are now all configured and administered from the Domain. Because of this architecture, it is very simple to alter architecture components if you find a suboptimal configuration and want to alter it in your environment. The key here is that you are not tied to any choices you make at installation time and have the flexibility to make changes to your architecture as your business needs change.
TIP >>>
While the architecture is very flexible and provides easy movement of services throughout the environment, an item to carefully consider at installation time is the name of the domain and its subsequent nodes. These are somewhat troublesome to change later because of their criticality to the domain. It is not recommended that you imbed server IP addresses and names in the domain name or the node names. You never know when you may need to move to new hardware or move nodes to new locations. For example, instead of naming your domain ‘PowerCenter_11.5.8.20’, consider naming it ‘Enterprise_Dev_Test’. This makes it more intuitive to understand what domain you are attaching to and if you ever decide to move the main gateway to another server, you don’t need to change the domain or node name. While these names can be changed, the change is not easy and requires using command line programs to alter the domain metadata.
In the next sections, we look at a couple of sample domain configurations.
Single Node Domain
Even in a single server/single node installation, you must still create a domain. In this case, all domain components reside on a single physical machine (i.e., node). You can have any number of PowerCenter services running in this domain. It is important to note that with PowerCenter 8 and beyond, you can run multiple integration services at the same time on the same machine – even in a NT/Windows environment.
Naturally this configuration exposes a single point of failure for every component in the domain and high availability is not available in this situation.
Multiple Node Domains
Domains can continue to expand to meet the demands of true enterprise-wide data integration.
Domain Architecture for Production/Development/Quality Assurance Environments
The architecture picture becomes more complex when you consider a typical development environment, which usually includes some level of a Development, Quality Assurance, and Production environment. In most implementations, these are separate PowerCenter repositories and associated servers. It is possible to define a single domain to include one or more of these development environments. However, there are a few points to consider:
If the domain gateway is unavailable for any reason, the entire domain is inaccessible. Keep in mind that if you place your development, quality assurance and production services in a single domain, you have the possibility of affecting your production environment with development and quality assurance work. If you decide to restart the domain in Development for some reason, you are effectively restarting development, quality assurance and production at the same time. Also, if you experience some sort of failure that affects the domain in production, you have also brought down your development environment and have no place to test a fix the problem since your entire environment is compromised.
For the domain you should have a common, shared, high-performance file system to share the centralized logging and checkpoint files. If you have all three environments together on one domain, you are mixing production logs with development logs and other files on the same physical disk. Your production backups and disaster recovery files will have more than just production information in them.
- For a future upgrade, it is very likely that you will need to upgrade all components of the domain at once to the new version of PowerCenter. If you have placed development, quality assurance, and production in the same domain, you may need to upgrade all of it at once. This is an undesirable situation in most data integration environments.
For these reasons, Informatica generally recommends having at least two separate domains in any environment:
- Production Domain
- Development/Quality Assurance Domain
Some architects choose to deploy a separate domain for each environment to further isolate them and to ensure no disruptions occur in the Quality Assurance environment due to any changes in the development environment. The tradeoff is an additional administration console to log into and maintain.
One thing to keep in mind is that while you may have separate domains with separate domain metadata repositories, there is no need to migrate any of the metadata from the separate domain repositories between development, Quality Assurance and production. The domain metadata repositories collect information based on the physical location and connectivity of the components and thus, it makes no sense to migrate between environments. You do need to provide separate database locations for each, but there is no migration needs for the data within; each one is specific to the environment it services.
Administration
The domain administrator has the access to start/shutdown all services within the domain, as well as the ability to create other users and delegate roles and responsibilities to them. Keep in mind that if the domain is shutdown, it has to be restarted via the command line or the host operating system GUI.
PowerCenter's High Availability option provides the ability to create multiple gateway nodes to a domain, such that if the Master Gateway Node fails, another can assume its responsibilities; including authentication, logging, and service management.
Security and Folders
Much like traditional repository security, security in the domain interface is set up on a “per-folder” basis, with owners being designated per logical groupings of objects/services in the domain. One of the major differences is that Domain security allows the creation of subfolders to segment nodes and services as desired.
There are many considerations when deciding on a folder structure, keeping in mind that this logical administrative interface should be accessible to Informatica Administrators only and not to users and groups associated with a developer role (which are designated at the Repository level). New legislation in the United States and Europe, such as Basel II and the Public Company Accounting Reform and Investor Protection Act of 2002 (also known as SOX, SarbOx and Sarbanes-Oxley) have been widely interpreted to place many restrictions on the ability of persons in development roles to have direct write access to production systems, and consequently, administration roles should be planned accordingly. An organization may simply need to use different folders to group objects into Development, Quality Assurance and Production roles; each with separate administrators. In some instances, systems may need to be entirely separate, with different domains for the Development, Quality Assurance, and Production systems. Sharing of metadata remains simple between separate domains, with PowerCenter’s ability to “link” domains, and copy data between linked domains.
For Data Migration projects, it is recommended to establish a standardized architecture that includes a set of folders, connections and developer access in accordance with the needs of the project. Typically this includes folders for:
- Acquiring data
- Converting data to match the target system
- The final load to the target application
- Establishing reference data structures
When configuring security in PowerCenter 8.5, there are two interrelated security aspects that should be addressed when planning a PowerCenter security policy:
- Role Differentiation – Groups should be created separately to define roles and privileges typically needed for an Informatica Administrator and for an Informatica Developer. Using this separation at the group level allows for a more efficient administration of PowerCenter user privileges and provides for a more secure PowerCenter environment.
- Maintenance of Privileges – As privileges typically are the same for several users within a PowerCenter environment, care should be taken to define these distinct separations ahead of time, so that privileges can be defined at a group level, rather than at an individual user level. As a best practice, users should not be granted user specific privileges, unless it is temporary.
Maintenance
As part of a regular backup of metadata, a recurring backup should be scheduled for the PowerCenter domain configuration database metadata. This can be accomplished through PowerCenter by using the infasetup command, further explained in the Command Line Reference. The schema should also be added to the normal RDBMS backup schedule, thus providing two reliable backup methods for disaster recovery purposes.
Licensing
As part of PowerCenter 8.5’s new Service-Oriented Architecture (SOA), licensing for PowerCenter services is centralized within the domain. License key file(s) are received from Informatica at the same time the download location for the software is provided. Adding license object(s) and assigning individual PowerCenter Services to the license(s) is the method used to enable a PowerCenter Service. This can be done during install, or add initial/incremental license keys can be used after install via the Administration Console web-based utility (or the infacmd command line utility).