00 - High Level System Design
High Level Architecture Diagram
The Data Center is designed as a service oriented architecture. The services within the architecture are organized into Composite Applications. Some services may belong to only one Composite Application while another belongs to many. There are 3 classes of service:
- System Management Services: These services are depended upon by all others and serve to provision, configure and monitor the running system.
- Shared Services: These services are utilized by multiple Application Services and are primarily data stores and COTS products.
- Application Services: These services are designed as microservices which generally do just one thing. When grouped together they can fulfill the needs of a business process.
By stitching together the different services into Composite Applications we can see the structure of software that supports processes described in 02 - Solution Architected Processes.
Architectural "-ility" Matrix
In order to guide the trade-offs that are faced in the creation of a system architecture, the following "-ility's" were used. With the exception of Portability, which was left unallocated to highlight its absence, each "-ility" is used by 1 or more composite applications. In the table below, each "-ility" has a brief description of what it pertains to.
| Composite Application | Architecture "ilities" | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Scalability | Maintainability | Extensibility | Reliability | Flexibility | Usability | Portability | Interoperability | Testability | Service-ability | Affordability | |
| Elasticity | Correct/Fix/Upgrade | Evolvability | Robust vs. Fragile | Adaptability and Agility | End-user Facing | Deploy-ability to Different Environments | Has External ICD | Testing ease and coverage | Monitor / ID Faults | Keeps Costs Down | |
| Summit Data Management | 1 | 1 | 0 | 1 | 0 | 0 | 0 | 1 | 1 | 1 | 1 |
| External Data Management | 0 | 1 | 0 | 1 | 0 | 0 | 0 | 1 | 1 | 1 | 1 |
| Science Data Processing Management | 1 | 1 | 1 | 1 | 1 | 0 | 0 | 0 | 1 | 1 | 1 |
| Science Data Discovery | 0 | 1 | 1 | 1 | 0 | 1 | 0 | 0 | 1 | 1 | 1 |
| Science Data Distribution | 1 | 1 | 0 | 1 | 0 | 1 | 0 | 0 | 1 | 1 | 1 |
| Operations Management | 0 | 1 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 1 | 1 |
Key Concept: Microservices and Service Oriented Architecture
A microservice architecture breaks apart functionality into smaller pieces which can be composed together to perform larger operations. The separation into small, decoupled services facilitates maintainability, extensibility, scalability, flexibility, and testability. Monoliths have a tighter coupling between the functions it provides, which can hinder extension and necessitate slower/larger releases to promote change. The main trade off is complexity. It can be harder to understand how an individual service fits in the bigger picture (something this documentation aims to mitigate with both process and system views).
Key Concept: Composite Applications
Composite Applications are simply a grouping of services that support a particular business process area. In the example below, there are 3 Shared Services and 1 Application Service that are part of both the Data Processing Management and External Data Management composite applications.
Key Concept: Competing Consumers
To facilitate the scaling of our application services, messages are exchanged over a queue. The messages are ensured to be delivered only once, but there can be multiple consumers on a queue. The services are designed in such a way that they can operate on a message independently from each other, thereby allowing as many consumers to attach to the queue as are necessary to keep up with the input load.
Key Concept: Service to Service Networking
In contrast with setting up network zones segregated by firewalls to prevent unintended conversation across zones, service based networking enables only those specific channels necessary between services. While implemented differently, it is as if each service had it's own fire-walled zone with openings only to those services to which it was required to communicate.
For more information, visit: https://www.consul.io/
Key Concept: Service Provisioning, Discovery & Health
Fundamental to the efficient operation of the data center system is the automated provisioning and orchestration of the resources within the data center. Rather than craft servers to fulfill a function, infrastructure is treated as code that when executed can configure the server as desired. This automation allows for rapid and repeatable deployments, making the best use of limited resources. Health information is fed both to the system orchestration system to enable intelligent routing of work to healthy services and to the monitoring system to facilitate alerting and ad-hoc monitoring of the infrastructure. With the tools to automate and monitor, it will be possible to extend the system to be able to dynamically adapt to its current state and load (the gray line).
For more information see:
Key Concept: Infrastructure View
The services described in the 02 - Composite Applications and 03 - Shared Services sections depend upon platforms that system orchestration provides.
Key Concept: Network Overview
CU OIT and DKIST Data Center staff share in the responsibility and administration for the DKIST Data Center Network. CU OIT is responsible for all of the ACLs and equipment north of and including the Data Center Arista switch(es), the uplink interface they provide to our top of rack infrastructure and the 1G switch(s) providing OOB access. Data Center Staff are responsible for Layer 2 at each of the TOR switches and any other networks that may be internal only. For example, the high speed/low latency "Infiniband" network.
