Remote Server Management — Example Remote Architecture
In our previous article from this series shared a look at the logical common architectural elements found in a remote server management solution. Having comp...
Join the DZone community and get the full member experience.Join For Free
In our previous article from this series shared a look at the logical common architectural elements found in a remote server management solution.
The process was laid out how we've approached the use case and how portfolio solutions are the base for researching a generic architecture.
It continued by laying out the process of how we've approached the use case by researching successful customer portfolio solutions as the basis for a generic architectural.
Having completed our discussions on the logical view of the architecture, it's now time to look at a specific example.
This article walks you through an example remote server management scenario showing how expanding the previously discussed elements provides an example for your own remote management scenarios.
As mentioned before, the architectural details covered here are base on real solutions using open source technologies. The example scenario presented here is a generic common architecture that was uncovered researching those solutions. It's our intent to provide guidance and not deep technical details.
This section covers the visual representations as presented, but it's expected that they'll be evolving based on future research. There are many ways to represent each element in this architecture, but we've chosen a format that we hope makes it easy to absorb. Feel free to post comments at the bottom of this post, or contact us directly with your feedback.
Now let's take a look at the details in this architecture and outline the solution for an example remote server management architecture.
Remote Server Management
The key to this remote server management architecture is the focus on providing the ability to maintain a consistent server estate across your hybrid cloud and data centers. This includes taking into account remote management, security, and data protection for full lifecycle.
Keeping that in mind, this architecture starts on the far left with the generic elements showing how a core data center such as the development teams manage their production. They have their projects in a source code management (SCM) system, which makes use of a method to build out their applications and images shown as a server image build pipeline, and some form of an image store or registry for distribution.
Moving to the top center you encounter the destinations for these workloads in the hybrid cloud infrastructure. It can consistent of traditional physical data center, private cloud, and public clouds. Each of these can be populated with a simplified generic RHEL host, which can be a physical, virtual, or container based machine along with the image registry used to manage the images for their particular destination as distributed by the central development image store.
A special case is shown in the edge / remote infrastructure representing the deployed devices out on the edge. The contents can be the edge devices and their applications, either containerised or not. The user might have these applications directly installed on the edge devices, or they might be hosted on an organisations infrastructure that the devices access remotely.
Next up, infrastructure management where we find the smart management element that's gathering input from all the deployed host machines from every destination and working together automation orchestration element to manage workloads. From the gained insights into your organisations workloads, it's possible to deploy new updates, manage security patching across all infrastructure destinations, roll out extra resources for surging demand on specific workloads, and so much more. These elements are supported by the cloud services to ensure consistency across your server estate.
Cloud services assist in managing responses and maintaining a repository of automated actions. Over time your automation needs change such that you have a repository of actions you might want to take, which is managed by the enterprise operating automation element. These are fed to the infrastructure management elements for use across the organisation. Also over time you'll develop plans to react on certain insights as they happen and this collection of plans can be found in the insights platform that works through insight services to support the infrastructure management elements.
As you can see, remote server management requires insights based plans and actions that are distributed by management elements that monitor and initiate actions ensuring consistency across your hybrid cloud infrastructure.
Remote Server Management Data
This look at a remote server management architecture data flow is not meant to be an all encompassing view of the exact flow. The idea is to give an example that you use to understand how elements and their data works through the entire remote management architecture.
With that in mind, the data flow shown is from the core data center on the left and works its way through the image repositories (images), automation orchestration (playbooks), and smart management (packages). From the image registries in each destination the data shows rolling out the workloads and server images onto the RHEL hosts.
In the cloud services, data flows show the gathering of insights and distribution of the automation action along with recommendations for the smart management to apply across the entire organisations architecture.
This concludes the look at the remote server management architecture.
This was just a short overview of the common generic elements that make up our architecture for a remote server management use case.
An overview of this series on remote server management portfolio architecture:
Catch up on any past articles you missed by following any published links above.
This completes the series and we hope you enjoyed this architecture for remote server management.
Published at DZone with permission of Eric D. Schabell, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.