{{announcement.body}}
{{announcement.title}}

Design Cloud-Native Secure Environment to Host Your Enterprise Application

DZone 's Guide to

Design Cloud-Native Secure Environment to Host Your Enterprise Application

This article would help to draft an infrastructure layout with Network, IP, VM design for your HA application to be hosted in HA Kubernetes cluster.

· Cloud Zone ·
Free Resource

Let's assume your organization is planning to develop an enterprise solution (name it opendrapp) using microservice architecture having below components and host them in a private cloud.

  • OpenDrApp-UI: Reactjs based app.
  • OpenDrApp-ACL: OpenID based user access control.
  • OpenDrApp-CRM.
  • OpenDrApp -PC &OrderCare with PMS, PIS, CAM, BM, WM, NIM etc
  • OpenDrApp-Charging.
  • OpenDr - Billing.

Database: Cloud-native database hosted on Kubernetes in HA &FT config.

Cache/key store: cloud-native hosted in Kubernetes in HA config.

Message broker: cloud-native hosted on Kubernetes in HA config.

Let's say architecture building blocks of the OpenDrApp would be something like below. Please note that each block may contain multiple individually deployable components. Only UI will be exposed outside.

Figure 1: Architectural building blocks

Environment Design

Let's try to design the environment to support the above application. We will try to design as vendor independent as possible them would discuss vendor specific alternative approach. We will be requiring below infrastructure to support the application.

  • Highly-available Kubernetes cluster to host application, database, message broker and key store solution.
  • Highly-available object storage. Which would be coupled with Kubernetes cluster to store persistence data of database, broker, key store and application logs etc.
  • A HA load balancer to route the external traffic to Kubernetes workers.


Figure 2: High Level Infra Design

Let's discuss the above design in details.

Network Design

  • Private subnet for OpenDrApp VM communication: It’s a 10.0.1.0/24 subnet with gateway 10.0.1.0. Router will have external link to organization’s internal satellite server to receive OS patches. All the VM will primarily be connected to this subnet. Kubernetes, Storage VMs will interact using this network. Will recommend multiple similar private subnet in case of network redundancy requirement.
  • One provider network towards organization internal management network. 
  • One Provider network towards traffic network which to be exposed externally and internally.

VM and IP Design

SL Purpose Hostname
(Replace Env with dev/lab/qlab/prod)
OS CPU Memory Root disk Additional Storage Interfaces-eth0 Interface- eth1 Virtual Interface
1 JumpBox envopendrjb001 CentOS/
Rhel
4 4 120 - Management – 10.140.43.45 PSN – 10.0.1.10
2 LB-1 envopendrlb001 CentOS/
Rhel
8 8 120
Traffic – 10.174.31.20 PSN- 10.0.1.11 Traffic VIP 10.174.31.23
3 LB-2 envopendrlb002 CentOS/
Rhel
8 8 120
Traffic – 10.174.31.21 PSN- 10.0.1.12 Traffic VIP 10.174.31.23
4 K8s Master envopendrkm001 CentOS/
Rhel
8 8 120
PSN- 10.0.1.13

5 K8s Master envopendrkm002 CentOS/
Rhel
8 8 120
PSN- 10.0.1.14

6 K8s Master envopendrkm003 CentOS/
Rhel
8 8 120
PSN- 10.0.1.15

7 K8s Worker envopendrkw001 CentOS/
Rhel
16 32 120 240 mounter on /var/data PSN- 10.0.1.16

8 K8s Worker envopendrkw002 CentOS/
Rhel
16 32 120 240 mounter on /var/data PSN- 10.0.1.17

9 K8s Worker envopendrkw003 CentOS/
Rhel
16 32 120 240 mounter on /var/data PSN- 10.0.1.18

10 K8s Worker envopendrkw004 CentOS/
Rhel
16 32 120 240 mounter on /var/data PSN- 10.0.1.19

11 K8s Worker envopendrkw005 CentOS/
Rhel
16 32 120 240 mounter on /var/data PSN- 10.0.1.20

12 K8s Worker envopendrkw006 CentOS/
Rhel
16 32 120 240 mounter on /var/data PSN- 10.0.1.21

13 K8s Worker envopendrkw007 CentOS/
Rhel
16 32 120 240 mounter on 14/var/data PSN- 10.0.1.22

14 K8s Worker envopendrkw008 CentOS/
Rhel
16 32 120 240 mounter on /var/data PSN- 10.0.1.23

15 K8s Worker envopendrkw009 CentOS/
Rhel
16 32 120 240 mounter on /var/data PSN- 10.0.1.24

16 Ceph Storage MN envopendrcs001 CentOS/
Rhel
8 16 120
PSN- 10.0.1.25

17 Ceph Storage MN envopendrcs002 CentOS/
Rhel
8 16 120
PSN- 10.0.1.26

18 Ceph Storage MN envopendrcs003 CentOS/
Rhel
8 16 120
PSN- 10.0.1.27

19 Ceph Storage OSD envopendrcs001 CentOS/
Rhel
16 32 120 2048 mounter on /var/data PSN- 10.0.1.28

20 Ceph Storage OSD envopendrcs002 CentOS/
Rhel
16 32 120 2048 mounter on /var/data PSN- 10.0.1.29

21 Ceph Storage OSD envopendrcs003 CentOS/
Rhel
16 32 120 2048 mounter on /var/data PSN- 10.0.1.30

JumpBox: This would be the infrastructure control node of the cluster. Lets say ansible orchestration node. Only this node will have management IP attached and this will connect to other nodes of the cluster with internal subnet IP.

LBs: Will host software load balancer top of VIP. Will have traffic interface to accept http load from outside and forward to Kubernetes workers over internal subnet.

Please follow the link to my blog to configure HA LB.

K8s Master/Worker: Kubernetes master/worker will have internal interface only. Master Worker communication will happen over internal subnet only. Also workers will access to object storage using internal subnet. Please adjust the number of worker nodes based on your need.

Please visit https://kubernetes.io/ or follow the link to my blog to setup HA K8s cluster.

If you wish to setup a secure private docker registry please follow the link to my blog.

Ceph MN/OSD: Ceph MN/OSD will also have internal interface only. K8s workers will interact over internal subnet. Please adjust the additional volume and number of OSD nodes based on your application’s replication, retention and data volume need.

Please follow the link to setup a HA ceph cluster.

Openstack related alternatives: LB nodes could be replaced by openstack load balancer. Please make sure to have proper network redundancy.

Google Cloud/AWS/ Azure alternatives: LB nodes to be replaced by load balancer service. Also proper network redundancy to be planed. Appropriate Kubernetes engine(managed k8s cluster) could also be considered. Ceph to be replaced by cloud storage.

Please do let me know in the comments section if you need any further information, clarification or help to setup HA DB, Key Store or broker setup.

Topics:
cloud (add topic), infrastructure, kubernates, security, software design

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}