This chapter is from the book
This chapter is from the book
This chapter is from the book
Deployment Models
There are a number of ways to deploy OIS in your environment. However, most implementations of OIS will fit into a small set of deployment models. The following sections will list the most common models for deploying OIS, explain where each model is best suited, and present the relative advantages and disadvantages of each.
Simple Deployment
The simple deployment model is the simplest and most basic deployment model for OIS. This model has all the OIS components installed on one server and can use either an existing SQL server or it might also have SQL running on the OIS server. Figure 3.5 shows a diagram of a simple OIS deployment.
)
Figure 3.5 Simple deployment model
This model is best suited for a proof of concept, or a limited pilot, and you can use it in a testing environment. However, the simple deployment model is not recommended for a production environment, as it does not provide any fault tolerance for the OIS components. In this model, you normally install all the OIS components on a single server and use an existing SQL instance to host the OIS datastore. If the datastore is also installed on the OIS server, the entire system is at risk if there is a failure.
Here are advantages of this model:
- Simplest model to install and configure
- Can run every component on a single server or virtual machine (VM)
- Limits licensing required
Here are the disadvantages:
- Does not provide policy failover
- All automation stops when server is offline
- Becomes a single point of failure especially if SQL is installed on the same server
Resilient Deployment
The resilient deployment model is most commonly used. This model is suitable from small businesses to large enterprises. The resilience is provided by having two or more Action Servers and clustering SQL Server. In this model the OIS components, the datastore, and automation targets are all on a centralized high-speed network.
For the purposes of this book, a centralized high-speed network is one in which average communication takes place in less than 50ms, and there is little or no data loss. Figure 3.6 shows a diagram of a resilient deployment model.
)
Figure 3.6 Resilient deployment model
This model is well suited for any implementation where the OIS components, datastore, and automation targets are all a centralized high-speed network.
Here are advantages of this model:
- Provides policy failover by having multiple Action Servers
- Provides resilient SQL through SQL clustering
- Provides a separate server to run the Action Server Watchdog service and provides alerting if an Action Server should fail
- Offers greater flexibility with additional Action Servers
Here are disadvantages:
- Additional resource demands because of extra Action Servers
- Additional resource demands from SQL clustering
- Additional management burden
Cross-Network Deployment
The cross-network deployment model is one in which Action Servers can reach across the network to perform automation on targets. This model is suitable for mid-size businesses or enterprises where remote sites have targets that require automation and are connected by a high-speed remote network, but these remote sites are ones in which it would be impractical or impossible to deploy an Action Server. Resilience is provided by having two or more Action Servers and by clustering SQL. In this model, the OIS components and the datastore are all on a centralized high-speed network and the automation targets are on high-speed remote networks.
For the purposes of this book, a high-speed remote network is one in which average communication takes places in less than 200ms, and there is little or no data loss. Figure 3.7 shows a diagram of a cross-network deployment model.
)
Figure 3.7 Cross-network deployment model
This model is suited for any implementation where the OIS components and datastore are on a centralized high-speed network and where automation targets are on high-speed remote networks. Because not all objects will work over a remote network (see the "Caution" note in this section), this model might not be possible in every environment where it is desired.
Here are advantages of this model:
- Provides policy failover by having multiple Action Servers
- Allows Action Servers to reach into other networks to perform automation, especially when the Action Server cannot be placed in the remote network
- Provides resilient SQL through SQL clustering
- Provides a separate server to run the Action Server Watchdog service and provides alerting if an Action Server should fail
- Offers greater flexibility with additional Action Servers
Here are disadvantages:
- Additional resource demands because of extra Action Servers.
- Additional resource demands from SQL clustering.
- Not all policy objects can tolerate this model.
- Requires additional configuration of firewalls to allow traffic from any of the objects used to pass between sites.
- Additional management burden.
Cross-Network Action Servers
The cross-network action server model is one in which Action Servers are placed on a remote network to perform automation on targets there. This model is suitable for mid-size businesses or enterprises where remote sites have targets that require automation and they are connected by a high-speed remote network; these remote sites are ones in which it is possible deploy an Action Server. Resilience is provided by having two or more Action Servers and by clustering SQL. In this model, the Management Server, Action Server Watchdog, and the datastore are all on a centralized high-speed network, and the Action Servers are on high-speed remote networks with the automation targets. Figure 3.8 shows a diagram of a cross-network action server model.
)
Figure 3.8 Deployment with Action Servers across networks
This model is suited for any implementation where the Management Server, Action Server Watchdog, and datastore are on a centralized high-speed network and where the Action Servers can be placed on the same high-speed remote network where the automation targets are located. This model requires that the remote network latency be less than 200ms. There must be little or no data loss; otherwise, this model will fail. Latency speeds in the 10-30ms range are recommended.
Here are advantages of this model:
- Provides policy failover by having multiple Action Servers
- Allows Action Servers to reside on remote networks to perform automation, assuming the network performance allows this
- Provides resilient SQL through SQL clustering
- Provides a separate server to run the Action Server Watchdog service and provides alerting if an Action Server should fail
- Can be used in some environments where the cross-network deployment model cannot
Here are disadvantages:
- Additional resource demands because of extra Action Servers
- Additional resource demands from SQL clustering
- Action Servers will tolerate only excellent network conditions in this model; without excellent conditions they will lose connectivity to the datastore
- Requires additional configuration of firewalls to allow SQL traffic between the sites
- Additional management burden
Multisite Manual Policy Sync
In some environments, the network performance will not be suitable to separate Action Servers from the datastore. If this is the case, it will be necessary to have one installation of the OIS components, including the datastore, at each location that requires automation. OIS installations are always standalone, and they will not communicate natively or share any data between installations (even when on the same network).
A multisite manual policy sync model is one where two or more installations of OIS are in use and there is a requirement or desire to use the policies on all installations. Because these installations will not be able to communicate with one another natively, policies that need to be shared must be exported manually and imported at the target OIS installation. This model provides a method to transfer policies but not policy data. Figure 3.9 shows a diagram of multisite manual policy synchronization.
)
Figure 3.9 Manual policy sync model
This model is best suited for environments where network conditions require several installations of OIS and these installations need to transfer policies with one another. Using a manual process to transfer policies between is not a desirable solution given the effort involved, but if more than one installation is required, there is no other way to transfer the policies.
Here are advantages of this model:
- Provides a method for using the same policies on remote OIS installations
- Can provide uniform automation to several remote sites
- Has all the advantages of a resilient model
- Offers flexibility in what policies are loaded to which installation
Here are disadvantages:
- No policy or state data is shared between installations.
- Requires manual effort to import or export policies.
- Installations have potential to become out of sync with one another.
Multisite Invoke via Web Services
In some environments, the network performance will not be suitable for Action Servers to be separate from the datastore. In this case, it will be necessary to have one installation of the OIS components, including the datastore, at each location that requires automation. OIS installations are always standalone and will not communicate natively.
A multisite invoke via Web Services model is one where the OIS installations communicate with one another over Web Services during custom policy execution. By installing the OOC, taking advantage of the Web Services, and building custom policies to use these components, you can have two standalone instances of OIS trade data or call actions on one another. Figure 3.10 shows a diagram of a multisite model using Web Services invocation.
)
Figure 3.10 Multisite invoke via Web Services
This model is best suited for environments where data needs to be shared between OIS installations or where one OIS installation provides a critical service to others (such as trouble ticket creation).
Here are advantages of this model:
- Allows policies to interact with remote installations and networks
- Allows OIS data to be shared between remote installations
- Has all the advantages of a resilient model
- Allows any networked OIS instance to trigger a specific function on another OIS instance
- Offers flexibility in having differing policies at different locations
- Allows policy execution across untrusted environments by providing credentials at the connection point using the Invoke Web Services object
Here are disadvantages:
- Requires special development of all policies to accept or transfer data
- Requires the Operator Console be installed on target OIS systems
- At risk for failure if network connection is lost
Multisite Hybrid Solution
The multisite hybrid solution is a combination of both the multisite manual sync and the invoked Web Services model. It provides a method to use the same policies in separate installations while also allowing those installations to communicate with one another at runtime and share data. Figure 3.11 shows a diagram of a multi-site hybrid solution.
)
Figure 3.11 Multisite hybrid solution
This model is best suited for environments where data needs to be shared between OIS installations or where one OIS installation provides a critical service to others (such as trouble ticket creation) while also providing common policies to multiple installations.
Here are advantages of this model:
- Provides a method for using the same policies on remote OIS installations
- Can provide uniform automation to several remote sites
- Has all the advantages of a resilient model
- Allows policies to interact with remote installations and networks
- Allows OIS data to be shared between remote installations
- Offers flexibility in what policies are loaded to which installation
Here are disadvantages:
- Requires special development of all policies to accept or transfer data
- Requires the OOC be installed on target OIS systems
- Requires manual effort to import or export
- At risk for failure if network connection is lost
- Installations have potential to become out of sync with one another
Multisite Isolated Deployment
If your environment's network performance is not suitable to separate your Action Servers from the datastore or security limitations make this a necessity, but you still need automation on remote sites, you will use an isolated deployment. In this situation, you will need to use a multisite isolated deployment model. This model is simply several unrelated installations that share no information or policy imports. Figure 3.12 shows a diagram of an isolated multisite OIS deployment model.
)
Figure 3.12 Isolated multisite OIS model
This model is used only when there is no desire or no way to share data or policies between installations. This model is rarely used.
Here are advantages of this model:
- Each installation is highly available
- Provides resilient SQL through SQL clustering
- Has all the advantages of a resilient model
- Provides a separate server to run the Action Server Watchdog service and provides alerting if an Action Server should fail
Here are disadvantages:
- No data is shared between installations
- All policies are designed and implemented separately
- Additional maintenance burden
- No policies are shared between installations