Question
What are the technical limitations of running one or more of the Kuali applications at a remote data center (such as the San Diego Super Computer Center)?
This anlaysis assumes the rational for co-location would be due to space limitations for additional servers here at the UC Davis campus. This does not address the issue of disaster recovery/high availability because that requires more architectural changes than simply running servers remotely.
Executive Summary
The current Kuali Rice architecture requires that Rice applications make direct database connections to the central Rice database for performance and transactional integrity of workflow documents. If client Rice applications are physically located a large distance from the Kuali Rice database there would be performance degregation for KEW transactions.
It is the technical workgroup's recommendation to keep all systems that are dependent on Rice located in the same physical location. As the Kuali Rice framework matures the database depenedey is expected to become less of a critical issue and then distributing the appliactions and RIce infrastructure may be technically fesable.
Kuali Application Issues to consider
Application Dependencies
Kuali Rice applications have three main depencenies on central infrastructure:
- Central Authentication
- Kuali Service Bus
- Kuali Rice database connection
Kuali KEW Architecture
Physical Data Center Issues to consider
Cost
The UC Davis San Diego Supercomputer Center (SDSC) Colocation Feasibility Study Report found that when amortized over 15 years the cost of co-locating at San Diego vs. building additional space on campus were nearly identical.
Performance
We have a 1GB network connection to San Diego for our administrative traffic. The remote locations would need to clarify what uptime requirements were required which would drive how we'd architect our network connectivity. For instance, we'd need to further investigate network redundancy to ensure a reliable connection. A backup connection could be purchased to reduce the risk of network interruptions.
Reliability of connection to remote location
Remote staffing
San Diego's service provides 'remote hands' that would rack servers, reboot systems, etc. Whatever co-location facility we'd use would need to provide this service since our system administrators and operators would no longer have physical access to the servers.
Remote infrastructure
An initial outlay of infrastructure would need to be installed to support UC Davis services at a remote location. Items such as Jumpstart servers, DNS servers, console servers would have to be purchased and installed.
Risk for tier-1 services
Is UC Davis ready to assume the additional risk for tier-1 services or would it make more sense to first move tier-2 and tier-3 services offsite?
Virtulization
As more services are virtualized on campus it would make the transition to a remote location more seamless. The virtual images of the servers could be transferred to a remote virtualization service with minimal downtime and without the need to move physical hardware.
Recommendation
In short, there are no technical issues with co-locating services remotely as long as the service owners are aware of the risks and work to mitigate them where possible.
Once the infrastructure for remote hosting is available, as new services are brought online hardware could be purchased and shipped directly to the remote location. Overtime the proportion of services at the remote location would grow while locally hosted services would shrink.