ServiceNow Self-Hosting blueprint – Part 2

[Gaurav Bajaj]

This is the second blog post from the self-hosting blueprint. In the initial post, we explored the essential planning steps necessary to begin self-hosting ServiceNow. This blog addresses the critical design factors to consider prior to commencing the installation process. 

1.   Performance & Scalability

In a self-hosted setting, it is your responsibility to accurately size the infrastructure to ensure you are able to provide exceptional user experience.

Here are the factors you should take into account:

• Right Sizing: Evaluate your expected user load, integrations, and transaction volumes. It is advisable to plan 2 application nodes per server. Begin with the recommendations from ServiceNow's official planning and sizing guides but conduct capacity planning exercises regularly to assess performance and determine the necessity for additional nodes.
• Vertical Scaling: This involves augmenting a single server with more resources (CPU, memory, disk I/O).
• Horizontal Scaling: This will be your greatest ally over time. Introduce more application nodes behind a load balancer to effectively distribute traffic.
• Server Specifications: It is crucial to focus on disk IOPS, memory speed, and network throughput. The System Activity Report (SAR) can be employed on Linux servers to monitor CPU, memory usage, and IO wait times at the server level. You can analyze historical SAR reports to identify performance bottlenecks.

2.   High Availability

In the SaaS model, ServiceNow ensures high availability using redundant data centers and failover mechanisms. However, when it comes to self-hosting, this responsibility falls on you.

Here are the key areas to concentrate on:

• Clustering: Set up multiple ServiceNow application nodes configured as a cluster behind a load balancer. This setup guarantees that if one node fails, the others can effortlessly take over the load.
• Database Redundancy: Establish either active/passive or active/active replication for your database backend. ServiceNow is closely integrated with its database—any failure in this area can lead to a complete system shutdown. According to ServiceNow's recommended databases,
  • Oracle databases offer high redundancy using Oracle RAC It is advisable to have this in place if you choose Oracle as your database.
  • A similar configuration is available in Maria DB with Maxscale

• Redundancy at Every Layer: From load balancers to network switches, ensure that your design incorporates N+1 redundancy. 

3.   Network Security

Ensuring security is of utmost importance, particularly when your ServiceNow instance is accessible from the external environment.

Some essential measures include:

• DMZ Zone for External Access: Position the ServiceNow application nodes that face the outside world within a DMZ (Demilitarized Zone) network segment. It is vital to keep internal nodes distinct from these external nodes. This is particularly relevant if you have users outside your organization or if you need to make ServiceNow available over the internet.
• Server Farm: It is advisable to house your database servers within server farms in such scenarios, utilizing a separate firewall. This may lead to increased network latency; therefore, it is important to align with your organization’s network security policy while ensuring that ServiceNow performance is not compromised.
• Web Application Firewall (WAF): Implement a WAF in front of your load balancer to safeguard against prevalent web vulnerabilities such as SQL injections, XSS, and others.
• Least Privilege Principle: Strengthen your internal network by limiting access to ServiceNow servers solely to essential systems and users. 

Rest of factors are covered in next blog!