Maximo Application Suite

MAS – Techno‑Functional

Search This Blog

Monday, February 2, 2026

MAS : Everything You Need to Know About Attachments Configuration in MAS Using S3 Block Storage

Maximo’s attachment architecture has evolved significantly in MAS, and S3‑compatible object storage is now the recommended pattern for storing attached documents. This article walks through the key concepts, required system properties, setup steps, and migration considerations when moving from traditional NFS/file‑based storage to S3.


Why Use S3 for Attachments?

S3‑style object storage offers several advantages over local NFS or file‑system‑based attachment storage:

  • Scalability: You can grow storage without worrying about local disk limits.​

  • Cost‑effectiveness: Pay‑as‑you‑go models reduce upfront hardware costs.​

  • Resilience and availability: Cloud‑provider S3 or self‑hosted MinIO can provide redundancy and high availability.

  • Simpler MAS upgrades: Using S3 from the start reduces post‑upgrade storage‑migration work.

In MAS, attachments are stored in an S3 bucket via the COSAttachmentStorage provider, which is also used in Maximo Manage 7.6.1.1+ and MAS‑based deployments.


Core S3 System Properties in Maximo / MAS

To route attachments to S3, you must configure a small set of system properties in the System Properties application.

PropertyPurpose / Value
mxe.cosaccesskeyS3 access key (HMAC or IAM‑style) from your COS/S3 provider. 
mxe.cossecretkeyS3 secret key (HMAC or IAM‑style). 
mxe.cosendpointuriRegional endpoint URI (e.g., https://s3.<region>.cloud-object-storage.appdomain.cloud for IBM COS). 
mxe.cosbucketnameName of the S3 bucket where attachments will be stored (e.g., maximo-doclinks). 
mxe.attachmentstorageAlways set to com.ibm.tivoli.maximo.oslc.provider.COSAttachmentStorage. 
mxe.doclink.securedAttachmentSet to true to hide raw file paths and encrypt attachment URLs. 
mxe.doclink.doctypes.defpathAlways cos:DOCLINKS\\default for S3. 
mxe.doclink.doctypes.topLevelPathsAlways cos:DOCLINKS for S3. 
mxe.doclink.path01Always cos:DOCLINKS=default for S3. 

After setting these, restart the Server(s) so Maximo starts writing new attachments directly to S3.


Setting Up S3 / IBM Cloud Object Storage

For IBM Cloud Object Storage (COS), the typical flow is:​

  1. In IBM Cloud, create an Object Storage resource (Standard plan).

  2. Create a bucket with a unique name, region, and storage class (e.g., Smart Tier).

  3. Generate Service Credentials with role Writer and enable HMAC credentials.

  4. From the COS UI, obtain:

    • access_key_id and secret_access_key (HMAC).

    • The regional endpoint URI (public HTTPS URL).

You can reuse the same COS instance across multiple MAS/Maximo environments by creating separate buckets per environment (DEV/QA/PROD).​

The same pattern applies to Amazon S3 or MinIO‑compatible S3‑style storage; you just plug in the corresponding access key, secret, endpoint, and bucket name.


Migrating from NFS/File‑Based Storage to S3

If you are upgrading from an on‑prem EAM instance using NFS‑based attachments, you must migrate existing files to S3 and update Maximo’s pointers.

Step 1: Prepare the S3 bucket

  • Create a bucket (e.g., maximo-doclinks) in your S3 provider.​

  • Ensure Maximo’s S3 credentials have write access to that bucket.​

Step 2: Copy files from NFS to S3

On a machine that can access the NFS mount (or directly on the Maximo app server), use the AWS CLI or similar tool:​

bash
aws configure # Enter accessKey and secretKey when prompted aws s3 cp /nfs_path s3://maximo-doclinks/ \ --endpoint-url http://<minio-host>:9000 \ --recursive

For MinIO or other S3‑compatible endpoints, include --endpoint-url. You can also use aws s3 sync or tools like rclone for incremental or large‑scale migrations.​

Step 3: Update MAXIMO.DOCINFO URLs

Once files are in S3, you must change the URL prefix in the MAXIMO.DOCINFO table so Maximo points to the S3‑hosted files instead of the old NFS path.​

A typical pattern is to update the URLNAME field from something like:

sql
UPDATE MAXIMO.DOCINFO SET URLNAME = REPLACE(URLNAME, '/nfs_path/', 'cos:DOCLINKS/') WHERE URLNAME LIKE '/nfs_path/%';

Exact SQL depends on your schema and current URL pattern; always test in a non‑production environment first.​


Important S3‑Attachment Gotchas

  • No subdirectories in S3 for new uploads: Maximo’s S3 implementation expects all attachment files at the root of the bucket; subfolders are ignored for new uploads.

  • Folder structure in Manage is cosmetic: Manage’s “Folders” UI does not map to physical S3 folders; the system still looks for files at the top level.​

  • Migration tooling in MAS: Maximo Manage ships with a file2s3.sh utility that can help convert file‑based attachments to S3, especially useful during MAS upgrades.

Sunday, January 11, 2026

MAS- Maximo Application Suite - Hardware vs Software Load Balancers—and How to Avoid Single Points of Failure

 When applications scale, one of the first critical components you’ll need is a load balancer. Its job is simple yet essential: distribute incoming traffic across multiple servers so no single server gets overwhelmed, and users get a fast, reliable experience.

This article explains the difference between hardware and software load balancers, how to configure load balancers so they don’t become a single point of failure (SPOF), and shows how this applies to IBM Maximo Application Suite (MAS)—especially for airport operations.


What Is a Load Balancer?

A load balancer sits in front of your application servers and routes requests to available, healthy instances. It ensures:

  • Better performance through parallel handling
  • Higher reliability via health checks and automatic failover
  • Cleaner operations by centralizing routing rules, TLS termination, and security policies

Hardware Load Balancers (Appliances)

Hardware load balancers are dedicated physical devices purpose‑built to manage and secure traffic at scale. They often include specialized hardware acceleration, advanced traffic management, and integrated security modules.

Typical characteristics:

  • Form factor: Physical appliances in data centers
  • Performance: High throughput, low latency, SSL/TLS offload
  • Capabilities: L4/L7 balancing, WAF, DDoS mitigation, GSLB
  • Operational model: Vendor-managed firmware/support
  • Cost: High (CapEx + support)

Examples: F5 BIG‑IP, Citrix NetScaler, A10 Networks

Best for: Regulated environments (airports, banks), extremely high traffic, strict security/compliance.


Software Load Balancers

Software load balancers run as programs on general-purpose servers or VMs—often containerized and easily automated. They shine in cloud and Kubernetes/OpenShift environments due to flexibility and cost‑effectiveness.

Typical characteristics:

  • Form factor: Software packages/services
  • Performance: Scales horizontally by adding instances
  • Capabilities: L4/L7 balancing, reverse proxy, observability integrations
  • Operational model: DevOps-friendly, infrastructure as code
  • Cost: Low to moderate; many open-source options

Examples: HAProxy, NGINX, Envoy, Kubernetes Ingress controllers (on OpenShift: HAProxy-based router pods)

Best for: Cloud‑native apps, microservices, rapid scaling, cost‑sensitive deployments.


Hardware vs Software: Quick Comparison

AspectHardware Load BalancerSoftware Load Balancer
NatureDedicated physical applianceSoftware running on servers/VMs
CostHighLow to moderate
ScalingScale up (bigger box)Scale out (more instances)
Cloud fitLimitedExcellent
Security featuresAdvanced, integratedAdd‑on or external integrations
OperationsVendor‑managedDevOps/IaC‑friendly

The Hidden Risk: Load Balancer as a Single Point of Failure

If all traffic enters through a single load balancer instance, your entire application depends on that device. If it fails, everything goes down—that’s a single point of failure (SPOF).

To build resilient systems, you must make the load balancer layer itself highly available (HA).


How to Configure Load Balancers for High Availability

1) Active–Passive (Failover Pair)

  • Setup: Two load balancers; one active, one standby.
  • Mechanism: Heartbeats/health checks; the standby takes over on failure.
  • Access pattern: Clients connect to a Virtual IP (VIP) that “floats” between nodes.
  • Pros: Simple, predictable
  • Cons: Standby capacity underutilized
    


2) Active–Active (Shared Traffic)

  • Setup: Two or more LBs active simultaneously.
  • Mechanism: Traffic split; surviving nodes absorb load on failure.
  • Access pattern: DNS‑based load balancing, anycast, or upstream equal‑cost routes to multiple VIPs.
  • Pros: Better utilization, higher throughput
  • Cons: More complex routing/state sync


3) DNS‑Based Load Balancing and GSLB

  • Concept: Spread traffic across multiple entry points (regions/data centers) using intelligent DNS.
  • Mechanism: Health checks at DNS layer; route users to nearest healthy site.
  • Pros: Geo redundancy, global failover
  • Cons: DNS TTL propagation introduces lag; careful policies required

4) Cloud‑Native HA (Managed Services)

  • Pattern: Use cloud managed LBs (AWS ALB/NLB, Azure Application Gateway/Front Door, Google Cloud LB).
  • Mechanism: Provider manages multi‑AZ redundancy, VIPs, health checks automatically.
  • Pros: Minimal ops burden, built‑in scaling/resilience
  • Cons: Vendor lock‑in, cost, fewer deep customizations vs appliances

MAS on Red Hat OpenShift: Where Load Balancers Fit

In typical MAS deployments (on‑prem or cloud), OpenShift runs MAS services (Manage, Monitor, Health, Predict, Mobility). Traffic reaches MAS via external LB (F5 or cloud LB) and then through OpenShift Ingress/Router pods (HAProxy).

Key HA points:

  • At least two router pods (OpenShift Ingress) per zone
  • External LB health checks target router pods only
  • Stateless services preferred; use shared stores for sessions if needed

Real‑World MAS Example: Airport Breakdown Maintenance

Scenario: An airport uses MAS Manage & Mobility for breakdown maintenance (e.g., a passenger boarding bridge or a conveyor subsystem fails). Users include operators, technicians, and planners.

Actors & Entry Points:

  • Operator raises an Incident via web/Mobile
  • Technician receives WO and executes via Mobility
  • SCADA event triggers Monitor/Health → auto‑WO (optional)


What happens during failures:

  • If F5‑A fails, the floating VIP moves to F5‑B (Active–Passive). Users continue seamlessly.
  • If a router pod dies, OpenShift reschedules it; the external LB’s health checks stop sending traffic to the dead pod.
  • If a MAS pod is unhealthy, the router stops routing to it (readiness/liveness probes), protecting user experience.

Business outcome:

  • No downtime in user access while assets are being fixed
  • Accurate downtime capture happens in execution by the technician
  • Auditable KPIs (MTTR, Availability) remain trustworthy

Health Checks, Failover, and VIPs: Core Building Blocks

Regardless of appliance or software:

  • Health Checks: Probe backends (HTTP 200, TCP connect) to avoid unhealthy targets
  • Heartbeats: LB‑to‑LB signals to detect failure and trigger takeover
  • Virtual IP (VIP): A single address exposed to clients; it moves to the healthy LB on failover
  • State & Persistence: Prefer stateless apps; if stickiness needed, use cookie‑based persistence or shared session stores (e.g., Redis)

Wednesday, October 22, 2025

IBM Maximo Application Suite - Understanding Sizing Parameters - Part I

When planning a deployment of IBM Maximo Application Suite (MAS), accurate sizing is critical to ensure performance, scalability, and cost-efficiency. The MAS Sizing Calculator includes several parameters that help architects and engineers tailor the infrastructure to meet business and technical requirements. Below is a detailed explanation of key sizing parameters commonly encountered in the calculator.


1. Enforce 3 Master + 2 Worker Nodes?

This parameter ensures the OpenShift cluster is configured with exactly 3 master nodes for high availability and 2 worker nodes to run MAS workloads. It represents the minimum viable cluster setup for production-grade deployments.

2. Installing into Existing OpenShift?

This flag indicates whether MAS will be deployed on an existing OpenShift cluster. If selected, the sizing calculator assumes that the base infrastructure is already provisioned, which can reduce the overall resource requirements and deployment complexity.

3. Install Manage w/Existing Database?

This option determines whether the Maximo Manage component will use an existing DB2 database. Leveraging an existing database can simplify deployment and reduce the need for provisioning new database resources.

4. Install Monitor w/Existing Database?

Similar to the previous parameter, this applies to the Maximo Monitor component. It checks if the component will connect to an existing database instance, which can be beneficial for integration with existing monitoring data sources.

5. Isolate DB2 Databases on Single Server?

This parameter ensures that all DB2 databases used by MAS are deployed on a dedicated server. Isolating databases can enhance performance, improve security, and simplify backup and recovery operations.

6. Isolate Visual Inspection GPU Nodes?

This setting allocates dedicated GPU nodes for the Visual Inspection component. GPU-intensive workloads, such as image recognition and AI-based inspections, benefit from isolated resources to avoid contention and ensure optimal performance.

7. Number of Development Environments

This parameter allows users to specify how many development or test environments are needed. Each environment adds to the overall resource requirements, so this input directly affects the sizing output.

8. Enforce Dev DBStorage = Prod DBStorage?

This ensures that the database storage allocated for development environments matches that of production environments. It promotes consistency across environments, which is especially useful for testing and validation.

Conclusion

Understanding and correctly configuring these parameters in the MAS Sizing Calculator is essential for a successful deployment. Each option influences the infrastructure footprint, cost, and operational efficiency. Whether deploying on ROKS (Red Hat OpenShift on IBM Cloud) or ROSA (Red Hat OpenShift Service on AWS), these inputs help tailor the solution to meet enterprise needs.