Edit

Share via

Deploy IBM Sterling Order Management on Azure

Azure Database for PostgreSQL
Azure Files
Azure Red Hat OpenShift
Azure Virtual Machines
Azure Virtual Network

This architecture illustrates an implementation of a Sterling Order Management Software (OMS) environment in Azure. This article doesn't go into detail about how to install Sterling OMS. To learn more about the installation process, see Installing Sterling Order Management Software.

The Red Hat logos are trademarks of Red Hat, Inc. No endorsement is implied by the use of these marks. Apache® and Apache ActiveMQ are either registered trademarks or trademarks of the Apache Software Foundation in the United States and/or other countries. No endorsement by The Apache Software Foundation is implied by the use of these marks.

Architecture

Architecture diagram that shows the components and services that support deployment of a Sterling OMS IBM order management system on Azure.

Download a Visio file of this architecture.

You can deploy a workload so that it's internally or externally facing. Use the configuration that best suits your requirements.

Workflow

The architecture meets infrastructure requirements in the following ways:

  • A container-hosting platform is used to deploy highly available workloads across availability zones. We recommend Azure Red Hat OpenShift.
  • A fully managed database service functions as the back-end database for the OMS system. Sterling OMS currently supports IBM Db2, Oracle Database, and PostgreSQL. We recommend Azure Database for PostgreSQL with the flexible server option.
  • A scalable and highly available setup provides an environment for running a message broker like IBM MQ that's compliant with the Java Message Service (JMS) API. The diagram doesn't include this setup. Depending on your requirements, it might be within your cluster or external to your cluster.
  • Private endpoints isolate and help secure network traffic to all connected services.
  • Additional, optional Azure virtual machines (VMs) are used for management and development purposes.
  • Premium and standard Azure Files shares provide storage for log files and other application configuration data.

Components

  • Azure Red Hat OpenShift provides highly available, fully managed OpenShift clusters on demand. These clusters are monitored and operated jointly by Microsoft and Red Hat.

  • Azure Virtual Network is the fundamental building block for private networks in Azure. Virtual networks are used for communication between nodes, Azure services, and hybrid connectivity needs.

  • Azure Files provides fully managed file shares in the cloud that are accessible via the SMB and NFS protocols. In this solution, Azure Files hosts the stateful data for the databases and systems that are inside the cluster.

  • Azure Bastion is a fully managed service that provides seamless, enhanced security RDP and SSH access to VMs without any exposure through public IP addresses. In this solution, Azure Bastion is optional. You can use Azure Bastion and a subnet to provide enhanced-security access to any of the worker nodes or optional jump box machines.

  • Azure Database for PostgreSQL is a fully managed relational database service that's based on the PostgreSQL database engine. Azure Database for PostgreSQL offers predictable performance and dynamic scalability, and is appropriate for business-critical workloads. Its flexible server deployment model provides granular control and flexibility over database management functions and configuration settings.

  • Azure Virtual Machines is an infrastructure as a service (IaaS) offer. You can use Virtual Machines to deploy on-demand, scalable computing resources. This solution uses Linux VMs in Azure to provide a jump box for management of your OMS Azure-based resources and services.

Alternatives

If you have network connectivity into your Azure environment, you can perform the installation from an existing machine instead of using an Azure Linux VM.

The following services typically aren't necessary, but they're effective alternatives:

  • IBM Db2 on Azure is an optional alternative to the flexible server model of Azure Database for PostgreSQL. If you run IBM Db2 on VMs, familiarize yourself with using Azure Load Balancer and Pacemaker clustering software to achieve high availability for your database servers.
  • Azure NetApp Files supports any workload type by providing high availability and high performance. Azure NetApp Files is ideal for IO-sensitive workloads, such as IBM Db2 workloads that run on Azure VMs.
  • Oracle Database on Azure is an optional alternative to the flexible server model of Azure Database for PostgreSQL.

Scenario details

IBM Sterling OMS is an order management system that delivers a complete omnichannel order fulfillment platform. This system includes features such as:

  • Real-time inventory visibility and demand.
  • Fully configurable order orchestration and workflows.
  • Reverse logistics for multi-channel returns and return order status.

A partnership between Microsoft and the IBM Sterling OMS team ensures that this solution is configured to run optimally on Azure. This article provides a design for running Sterling OMS 10.0 and later versions on Azure for customers who have support from IBM and a partner for installation. For answers to product-specific questions, contact your IBM team.

Potential use cases

Many industries and sectors use OMS solutions, including:

  • Retail
  • Ecommerce
  • Manufacturing

For more OMS use cases, see IBM Sterling Order Management.

Recommendations

This guidance supports Sterling OMS 10.0 Q3 2022 and later versions. These versions provide the best integration options with Azure because they support PostgreSQL and the Azure Red Hat OpenShift container platform. Before you build out your own deployment, use QuickStart Guide: Sterling Order Management on Azure to deploy Sterling OMS. When you then understand how the deployment and configuration work, you can more quickly determine your implementation's design requirements.

Microsoft works closely with IBM and other partners to ensure that the guidance, architecture, and quickstart guide give you the best experience on Azure. These resources follow the best practices as outlined in the Microsoft Azure Well-Architected Framework. For support beyond this documentation, contact your IBM account team.

Before you proceed with your deployment, answer the following questions about your design:

  • Is your deployment of Sterling OMS a new one, or are you migrating an existing deployment to Azure?
  • What back-end database platform do you plan to use? What size database will you need for your data?
  • What type of JMS-based message broker do you plan to use?
  • Where do you plan to deploy the messaging system:
    • In the same OpenShift cluster?
    • External to the cluster on a different platform or on VMs?
  • Do you have an existing container registry, and do you plan to keep using it?
  • What number and sizes of VMs do you need for your worker nodes?
  • What are your encryption-related security requirements?
  • What are your access requirements, and what identity provider (IdP) integration considerations do you have?
  • What are your connectivity needs? What firewall rules do you need to connect to internal and external (egress) services?
  • What's your strategy for high availability and disaster recovery?

Sterling OMS

Sterling OMS version 10.0.2209.0 has been tested on Azure. We recommend that you use the latest version of Sterling OMS.

Before deploying your Azure resources to support your Sterling OMS environment, familiarize yourself with the following requirements:

Azure Red Hat OpenShift

Sterling OMS has been tested with Azure Red Hat OpenShift version 4.10.15. Before you deploy Azure Red Hat OpenShift:

  • Decide on a domain. When you deploy Azure Red Hat OpenShift, specify a domain name that gets appended to all services that get deployed in your cluster.
  • Determine your API and ingress visibility. Decide how you want your OpenShift cluster API (for management) and ingress (for deployed applications and services) to be internet-facing. If you use private connectivity to hide your API or ingress, you can only reach these endpoints from a machine that can reach the network where you deploy your service.
  • Calculate your control and worker VM sizes and counts. In Azure Red Hat OpenShift, the control count is a fixed number, with a minimum recommended size. Your worker nodes, which run your application workloads like Sterling OMS, are sized separately. When you deploy your instance, consider the required number of worker nodes in your cluster, plus the appropriate size of each. You might need to do some testing and validation to determine the correct numbers and sizes. These values depend on the number of agents in your deployment and the number of pods for each agent type that you run. After deploying, you can adjust these values when you need to scale.

For more information, see Before Your Begin for Azure Red Hat OpenShift.

Size your environment

We recommend that you use the latest Ds series VMs as your worker nodes. Examples are the Dsv3, Dasv4, Dsv4, Dasv5, and Dsv5 series. The latest versions of these VMs provide the best performance. When you deploy more nodes, only use VMs that have premium storage.

Database specifics

Because Sterling OMS has various back-end database options, it's important to first decide which platform to host your database on. Then you can make decisions about the size of that platform. Keep the following general guidelines in mind during this process:

  • Azure Database for PostgreSQL, flexible server deployment model: Due to the nature of its scale and redundancy options, the flexible server model of Azure Database for PostgreSQL is the preferred method for hosting Sterling OMS workloads in Azure. When you deploy your instance:
    • Select the compute tier that matches your usage patterns. We recommend that you start with a general purpose tier and select an appropriate number of cores. Also note that your CPU, memory, and IOPs are tied to your compute size selection.
    • Add appropriate storage. Also remember that increased storage increases cost, and you can't shrink your provisioned storage. As a result, it's important to know your initial data size and predicted growth.
    • Adjust server parameters such as max_connections that affect your agents' ability to maintain connectivity to your database.
  • Db2 on VMs: When you run Db2 on Azure VMs, there are several complex factors that you need to address, such as performance and availability. For a detailed article about a high-performance Db2 deployment on Azure, see High availability of IBM Db2 LUW on Azure VMs on Red Hat Enterprise Linux Server. That article walks through sizing and performance considerations. It also shows you how to deploy a high availability Db2 cluster that uses Pacemaker.
  • Oracle: If you currently use Oracle Database, or if you plan to migrate to Oracle, familiarize yourself with the following resources for running Oracle workloads on Azure:

Message queue specifics

Sterling OMS requires a JMS-based message broker. Most commonly, IBM MQ is used. The best way to run a highly available IBM MQ instance in Azure is to use the IBM MQ Helm Charts for Kubernetes deployments. You can deploy these charts into your existing Azure Red Hat OpenShift cluster onto separate workers to isolate your workloads. You can also manually deploy and install IBM MQ onto VMs if you prefer.

As part of the standard deployment, you can define your queues at deployment time, which reduces the configuration time that's needed to spin up your instances. The standard deployment creates one active and two passive instances of your queue manager. When your deployment is complete, you can use SSH to connect to the current leader pod and define your JMS bindings file. You can then use that file to create your configuration map for your Sterling OMS deployment.

IBM also supports other JMS-based message queuing systems, such as Apache ActiveMQ. For more information, see Message queues in Sterling Order Management Software. Your deployment options vary per solution.

Considerations

These considerations implement the pillars of the Azure Well-Architected Framework, which is a set of guiding tenets that you can use to improve the quality of a workload. For more information, see Microsoft Azure Well-Architected Framework.

Security

Security provides assurances against deliberate attacks and the abuse of your valuable data and systems. For more information, see Overview of the security pillar.

Maintaining access and visibility into the maintenance lifecycle of your assets can be one of your organization's greatest opportunities to operate efficiently and maintain uptime. To help improve the security posture of your environment, it's important to use secure authentication and to keep your solutions up to date. Use encryption to help protect all data that moves in and out of your architecture.

Azure delivers Sterling OMS by using the models of IaaS and platform as a service (PaaS). Microsoft builds security protections into the service at the following levels:

  • Physical datacenter
  • Physical network
  • Physical host
  • Hypervisor

Carefully evaluate the services and technologies that you select for the areas above the hypervisor, such as the latest patched version of Azure Red Hat OpenShift for a major release. Be sure to provide the proper security controls for your architecture. You're responsible for patching and maintaining the security of the IaaS systems. Microsoft takes that role for the PaaS services like Azure Red Hat OpenShift. Even though you can initiate an upgrade for Azure Red Hat OpenShift, it's fully managed by Microsoft and Red Hat. For more information about patching and upgrading Azure Red Hat OpenShift, see Upgrade an Azure Red Hat OpenShift cluster.

Use network security groups to filter network traffic to and from resources in your virtual network. With these groups, you can define rules that grant or deny access to your Sterling OMS services. Examples include:

  • Blocking access to all other parts of your deployed infrastructure, such as specific ports and services that your message broker or back-end database uses.
  • Controlling which locations have access to Sterling OMS and the OpenShift cluster.

The port numbers and ranges that you need to open depend on many factors. Some to consider are:

  • Port 443, for service-to-service communication.
  • Database-specific ports such as port 5432 for the flexible server option of Azure Database for PostgreSQL.
  • Message queue ports such as port 1414 for IBM MQ.

Also consider these points:

  • Azure Red Hat OpenShift cluster nodes must have outbound internet access. If you can't provide this access, these nodes need, at a minimum, access to the Azure Resource Manager and service logging endpoints.
  • IBM provides guidance for implementing multiple Sterling OMS applications that share common services like a back-end database. Such deployments also have intra-application firewall considerations. For more information, see Opening firewall ports for intra-app communication.

If you need access to your other, non–Azure Red Hat OpenShift nodes, you can optionally use Azure Bastion to access your VMs. For security reasons, don't expose VMs to a network or the internet without configuring network security groups to control access to them.

Server-side encryption (SSE) of Azure disk storage helps protect your data. SSE also helps you meet organizational security and compliance commitments. With Azure managed disks, SSE encrypts the data at rest when persisting it to the cloud. This behavior applies by default to both OS and data disks. OpenShift uses SSE by default. Azure Red Hat OpenShift also supports customer-managed encryption keys (CMEK) for the OS disks in your cluster.

Authentication

You should configure OAuth for Azure Red Hat OpenShift. For more information, see Overview of authentication and authorization in the Azure Red Hat OpenShift documentation.

Protect your infrastructure

Control access to the Azure resources that you deploy. Every Azure subscription has a trust relationship with a Microsoft Entra tenant. Use Azure role-based access control to grant users within your organization the correct permissions to Azure resources. Grant access by assigning Azure roles to users or groups at a certain scope. The scope can be a subscription, a resource group, or a single resource. Be sure to audit all changes to infrastructure. For more information about auditing, see Azure Monitor activity log.

Cost optimization

Cost optimization is about looking at ways to reduce unnecessary expenses and improve operational efficiencies. For more information, see Overview of the cost optimization pillar.

A standard deployment of Sterling OMS consists of the following components. You can adjust many of these compute-based resources to meet your needs. For instance, you can scale up your IBM MQ agent nodes to allow greater throughput.

Azure Red Hat OpenShift (for OMS)

  • Three control VMs (Standard_D8s_v5)
  • Three worker VMs (Standard_D8s_v5)

Additional resources

  • One virtual network (/16), with the following subnets considered:
    • Azure Red Hat OpenShift control node subnet (/24)
    • Azure Red Hat OpenShift worker node subnet (/24)
    • Data subnet, if needed (/27)
    • Additional VM subnet, if needed (/27)
    • Management subnet, if needed (/30)
  • One instance of Azure Database for PostgreSQL with the flexible server option
  • One instance of Azure Container Registry
  • Two Azure Storage accounts
  • Three DNS zones
  • Two load balancers
  • One jump box VM
  • Azure Bastion

Individual deployments can differ, for instance, if you run Db2 on Azure VMs, or if you deploy IBM MQ into your Azure Red Hat OpenShift environment. To review an example estimate, use the cost calculator. Configurations vary, so verify your configuration with your IBM sizing team before you finalize your deployment.

Reliability

Reliability ensures your application can meet the commitments you make to your customers. For more information, see Overview of the reliability pillar.

Azure Red Hat OpenShift has built-in capabilities for self-healing, scaling, and resilience to ensure that Azure Red Hat OpenShift and Sterling OMS work successfully. Azure Red Hat OpenShift and Sterling OMS have been designed for parts that fail and recover. A key requirement for self-healing is that there are enough worker nodes. To recover from a zone failure within an Azure region, your control and worker nodes must be balanced across availability zones.

Sterling OMS and Azure Red Hat OpenShift use database storage to persist state outside the Kubernetes cluster. Logs and other application resources are persisted to a storage account. To ensure that the storage dependencies continue to work during a failure, use zone-redundant storage whenever possible. This type of storage remains available when a zone fails. Your database deployment should also take multi-zone configurations into account.

Because human error is common, deploy Sterling OMS by using as much automation as possible. For some sample scripts for setting up full, end-to-end automation, see QuickStart Guide: Sterling Order Management on Azure on GitHub.

Deploy this scenario

Before you start, review the requirements for Sterling OMS in System Requirements. Also ensure that you have the following resources available:

  • Access to an Azure subscription with Reader permission.
  • An application registration or service principal name that has Contributor and User Access Administrator permissions to the subscription.
  • A domain or delegated subdomain to an Azure DNS zone.
  • An IBM Sterling OMS entitlement key.
  • IBM-recommended cluster sizing.
  • An existing virtual network or a new virtual network, depending on your requirements. For an example of creating a new virtual network with two empty subnets, see Tutorial: Create an Azure Red Hat OpenShift 4 cluster.
  • High availability and disaster recovery requirements for your specific deployment.
  • An OMEnviroment configuration file, omenvironment.yaml, to use when you deploy Sterling OMS via the OpenShift Operator Catalog.

For a step-by-step guide for installing Azure Red Hat OpenShift and Sterling OMS on Azure, including how to address the prerequisites, see QuickStart Guide: Sterling Order Management on Azure.

Deployment considerations

The current best practice is to deploy workloads by using infrastructure as code (IaC) rather than manually deploying workloads, because manual deployment can result in misconfiguration. Container-based workloads can be sensitive to misconfiguration, which can reduce productivity.

Before you build your environment, review QuickStart Guide: Sterling Order Management on Azure to develop an understanding of the design parameters. The quickstart guide isn't intended for a production-ready deployment, but you can use the guide's assets to get to a production-grade mechanism for deployment.

IBM offers specialized services to help you with installation. Contact your IBM team for support.

Contributors

This article is maintained by Microsoft. It was originally written by the following contributors.

Principal authors:

Other contributors:

To see non-public LinkedIn profiles, sign in to LinkedIn.

Next steps