This article provides examples of the primary deployment architectures and options for Cruz
CruzNow - Cloud Hosted or Private Cloud
The cloud hosted offering provides the same features as on-premise deployments. The cloud hosted software can be deployed in a variety of configuration described below and on a variety of cloud providers. The architectures below describe options for on-premise deployment. For CruzNow cloud deployment all or some of the distributed components are deployed in the cloud to provide a fully hosted solution. Refer to CruzNow for more product information.
Please note that cloud hosted options such as AWS, the cloud platform may provide its own options for High availability and geographic redundancy. In this case the HA option described below may not be necessary.
CruzNow cloud deployments on AWS require a Virtual Private Connection (VPC) from the cloud in order access the target networks. The VPC provide a secure connection and access to a corporate network. You may also use multiple VPC to access remote sites outside of a central corporate network. CruzNow is supported on all cloud provider platforms. Other cloud providers will also have their own method of providing a secure connection the cloud similar to the AWS VPC. This connection to CruzNow is the only additional infrastructure needed. All other architectural considerations and options are unchanged.
Operating systems and system sizing is similar to on-premise solutions. refer to the sizing KB article.
With CruzNow, customers only interact with UI to perform the necessary day-to-day operation using all of the features available in the software. CruzNow Software upgrades, maintenance and monitoring are performed by Dorado Software as part of a service.
And finally, a customer may take any Cruz installation package they have purchased and install it on their own Private (or Public) cloud.
Single Server
Single server deployments are the default in most cases. The standard packages available online will auto install as a single server deployment. In most cases the installation will auto-set the necessary memory allocation needed based on the number of device specified at install time. To see the hardware recommendations and values that can be tuned to optimize performance, refer to the sizing KB article
Distributed (Non-HA)
If High Availability (redundancy) is not required, the components may be distributed to provide improved performance when single server resources are limited or to place mediation and file servers closer to the resources under management. This option also provide scalability beyond a the capacity of a single server deployment. Server may distributed locally within one data center or in remote locations. When mediation servers are distributed into a remote location, the architecture allows standard protocols to be utilized and confined between the mediation servers and the managed network. The mediation server then uses secure communication across the internet (or a VPN) back to the Application server.
While VMs are depicted in this image, server can be physical or virtual
Distributed (with HA)
If High Availability (redundancy) is required, the various components can be installed with additional instances to provide HA and failover. The HA option can also scale and grow as more device, locations etc. are brought under management.
In a distributed or HA deployment the Web Server and Applications server are deployed on the same server. The web server UI takes users request and send them to the application server. The Application server will with go to the db server to return data to the UI or it will send a request to the mediation server which communicate with the network. The application Server in an HA deployment can be clustered as shown. The number of application servers in the cluster can grow to meet scalability and HA needs. The application server can be sized and scaled with CPU, Memory and Disk space to support the system needs. The application servers may also be distributed over a geographic area to allow for geo-redundancy in the event of total failure in one location. All servers in an application server cluster are always up and active.
The mediation servers may also be in one location or distributed to remote locations. The mediation servers can be paired in active-active or active standby mode. Mediation servers are installed to mediate communication between the Cruz NMS and the Network. The servers like application servers are sized/scaled based on the number of device and the expected network activity. One med server may support up to 5000 devices or more. When paired for redundancy any failed server communication will immediately failover to the working med server. There are potentially performance gains when mediation servers are placed closer to the network. Another unique advantage is secure communication. The med server to application sever communication uses SSL encryption. When/if a remote location is using unsecured links, this additional security may be necessary.
The Db server is can be the embedded Mysql or the Customers Oracle Db. Both are sized and scale with CPU, mem and Disk resource allocation. Both options support HA and Geo-location of the replication Db's. The replication and HA functions are features native to each respective vendor's implementation.
Load balancers are not part of the Cruz Software. These are generally any device that can provide a proxy function were users are pointed to an active Cruz web server. For example if there is are 5 web servers, each has their own IP address or DNS name. Without a load balancer a user can enter any one of the 5 ip addresses in web browser to access Cruz. But, what if that server is down? In order to provide seamless access, the load balancer is 1 IP /url a user can go to and the load balancer will then redirect the user to an "up" web server. This ensures reliable access to Cruz despite a failure on of a web server.
Minimum HA deployment
Example of a minimum HA deployment for DR/Geographic redundancy.
Distributed and HA deployments: Additional Performance and Security Considerations
Latency and Links
- Slow device response or general network latency related to limited bandwidth in the managed-network links may result in timeouts when communicating with the mediation server(s). This may result in failed operations. Cruz allows the network timeout values to be adjusted to accommodate these conditions.
- Links between the Cruz servers must to have sufficient link bandwidth to ensure communication. All inter-server communication link should be 10Gb links or better. This applies to both local as well and geographically distributed servers and includes:
- Links between application and mediation servers
- Links between clustered elements such as application server to application server clustering.
- Links between the application server and the Db(s)
- Links between the Db servers also require low link latency for Cruz Application performance as well as for Db replication and redundancy.
- If server links are too slow, It may lead to Cruz issuing "server down", "server unavailable" alerts or alerts indicating that a mediations server, for example, is queueing data that it is unable to send.
Cluster Security
- The Cruz Servers generally use RMI protocol for communications between servers. Typically managing a remote site over a WAN may require placement of a mediation or web/application server or Db in a remote locations. To secure these links, VPNs or existing encrypted links may be used or SSL may be configured, in Cruz, to encrypt the communication.
- A key security feature is this ability to encrypt traffic between a remote mediation server (a remote site) and the application server where traffic is flowing over the internet.
For additional details, refer to Distributed/HA portion of the the user guide.