Architecting IBM Cognos for Multi-AZ
The Familiar
The core components of a traditional Cognos deployment remain consistent even when deploying on AWS. There will still be gateways, dispatchers, and content managers regardless of the deployment location. These servers (instances) can be managed in the same way as on-prem servers. RDP or SSH can be used to remote into the instances and manage them using tools a veteran Cognos administrator would find familiar.
The Unfamiliar
The same set of business requirements that guided architectural decisions for on-prem deployments still exist when deploying on AWS. However, there are now new technologies and design choices available to solve these requirements that were not available with an on-prem solution. One of these new design patterns is Multi-AZ. What is Multi-AZ? What’s an AZ? Let’s dive in and explore how understanding Multi-AZ can enhance a Cognos deployment.
Single-AZ vs Multi-AZ
A key concept to understand when migrating to AWS is the physical distribution of cloud resources. AWS organizes its global infrastructure into Regions and Availability Zones (AZ). Yes, there are Edge Locations, Outposts, Local Zones, and Wavelength, too. But those are all out-of-scope for this discussion.
An AZ consists of one or more discrete data centers within a Region. When you deploy resources in AWS you must define the Region those resources are deployed to and one or more AZs. AWS best practices encourage deployments to be spread across multiple AZs (Multi-AZ) instead of isolating them to a single AZ. Why is this recommended? Even the largest Internet companies can face outages. Implementing a Multi-AZ deployment makes your application more resilient by limiting the impact of a single networking failure or data center outage.
If you’ve been following along with this series, you’ve already seen an example of Multi-AZ deployments when we discussed database types to host the Cognos databases. Now we want to move beyond the database tier and explore how Multi-AZ can benefit the application tier.
Cognos Multi-AZ
Most disaster recovery plans we’ve seen implemented for Cognos involve a secondary data center that has a few servers set aside for Cognos. Those servers may or may not even have Cognos installed. They usually sit idle for years waiting to be turned on should the worst happen. If the worst does happen, rolling over to that secondary site is typically a slow, manual process. Database backups need to be restored. DNS entries need to be updated. The software needs to be configured and started. During the entire process, there is lots of finger-crossing hoping that it all comes back online as planned. Which, of course, it never does.
A Multi-AZ deployment on AWS can vastly improve an environment’s failover capability by essentially running an entire secondary site in your base Cognos deployment. To see how this would look in practice, let’s take a look at a typical Cognos architecture and expand it to be Multi-AZ.
A common Cognos architecture we see involves running two dispatchers and separate primary and stand-by Content Managers. Deploying this kind of architecture in a single AZ behind an ALB would look like the below diagram. This is comparable to running Cognos in a single data center.
But we’re in the cloud. Why limit ourselves to one AZ? Splitting those Cognos resources across two AZs gives us greater resiliency by having automatic failover between AZs (data centers) should one go down. Moving our architecture from Single-AZ to Multi-AZ would look like this example.
If the primary AZ does go down, the environment remains running because the resources in the secondary AZ are still functional.
These architectures don’t have to be limited to just two AZs. Larger deployments can be spread across three or more depending on the Region. However, while you can deploy Cognos resources across more than three AZs, there would likely be diminishing returns from that large of a footprint. Companies looking to deploy across more than three AZs would be better suited to develop a DR plan that includes a hot, warm, or cold site in a separate Region.
The above examples center on larger implementations with single-purpose servers. But what about smaller deployments with dual-purpose servers? The same Multi-AZ approach can be applied to smaller deployments as well. Below is an example of a smaller architecture still using Mult-AZ.
Balance
The key with any of these architectures is balance. The most important design element to remember is that application components must be mirrored across each AZ. For example, it wouldn’t matter if additional dispatchers and content managers were deployed in different AZs if the environment is deployed with a single gateway server.
It will functionally be operating as a single AZ deployment because if the primary AZ goes down, the entire environment will go down.
Conclusion
Understanding AZs and how they can be utilized is critical when migrating Cognos to AWS. Implementing Cognos as a Multi-AZ deployment can greatly increase the resiliency of an environment and create a more stable, predictable experience for end users. Whether you are just starting your AWS journey, or already deployed on AWS, we strongly encourage you to explore a Multi-AZ deployment for your Cognos environment.
Cognos to AWS Blog Series
Join us here for more updates to this series to address questions and discuss patterns to consider when migrating Cognos to AWS. If you need help sooner, reach out to us now! We’d love to have a conversation with you about your AWS migration journey.
Next Steps
We hope you found this article informative. Be sure to subscribe to our newsletter for data and analytics news, updates, and insights delivered directly to your inbox.
If you have any questions or would like PMsquare to provide guidance and support for your analytics solution, contact us today.
