Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 65 Next »

This is what we do in the implementation phase:

Set up remote access to the customer's Amazon EC2 instance

WSO2 does all Managed Cloud deployments in an Amazon Virtual Private Cloud (Amazon VPC). A VPC enables you to launch Amazon Web Services (AWS) into a virtual network that you define. A VPC improves the security of your data by providing network-level control and isolation for the AWS. You can keep your data and configurations in a private space and expose them through the DMZ. This virtual network closely resembles a traditional network, but with improved security and scalability.

We access the customer's Amazon EC2 instance over SSH only, with a Bastion host working as the SSH gateway. The Bastian host can either reside in the VPC or in the customer's data center as depicted in the diagrams below:

  • The Bastian host is in the VPCThe Bastion host is in the public subnet and allows SSH traffic only to the WSO2 network via a non-standard port. All other hosts are configured to accept SSH requests from the Bastion host only.
  • The Bastian host in the customer's data centerThe Bastion host is in the customer's data center, and the other hosts are configured to accept SSH requests from the Bastion host only. When WSO2 DevOps want to connect to the Bastion host via SSH, they do it remotely via a client console.

Set up a domain name system (DNS)

The Domain Name System (DNS) is a server that translates domain names, which are alphanumeric and can be easily remembered by humans, to numerical IP addresses that are recognized by the Internet. The DNS is the Internet's primary directory service that determines which physical server a request should be routed to when a visitor calls a domain name over the Internet.

For the servers in the customer's data center to connect to the virtual machines in the Amazon VPC, we need domain name to IP mappings set up in a DNS server. Customers can either use their own DNS servers for this or allow WSO2 to use the Amazon Route53 service as depicted in the diagrams below:

    • The DNS is in the VPC: WSO2 uses an Amazon Route53 instance to maintain the domain name to IP mappings related to the Managed Cloud. 
    • The DNS is in the customer's data center: WSO2 provides the domain name to IP mappings related to the Managed Cloud to the customer, who manages the DNS server in the customer's data center.

Set up an SMTP server

SMTP is shortened for Simple Mail Transfer Protocol, which is an Internet standard for email transmission. An SMTP server is a computer running SMTP, and which delivers email messages to their corresponding recipients.

The customers can either use their own SMTP servers or allow WSO2 to use Amazon SES. Shown below is how an SMTP server in the customer's data center communicate the WSO2 EC2 instance in the Amazon VPC.

Set up an NTP server

NTP is shorted for Network Time Protocol, which is a networking protocol for synchronising time over a network. Shown below is how the NTP server in the customer's data center communicates with the WSO2 virtual machines in the Amazon VPC over NTP.

Set up the environments

The WSO2 Managed Cloud offering is for hosting and maintaining WSO2 products in a Amazon EC2 instance that the customer purchases. Here are the tasks performed by the WSO2 Managed Cloud team when setting up the environments. For additional services, the customer can purchase WSO2 Support.

Tasks within the WSO2 Managed Cloud SLATasks covered by WSO2 Support services
Set up an AWS account upon the customer's request (excluding the costs pertaining to the hosting services).

Application and service development and deployment.

Set up the virtual machines and networking in the customer's AWS.

IT management (creating users

Deploy the WSO2 products that the customer purchased according to the deployment architecture that was created in the Planning phase.

System quality assurance.

Create user accounts with admin privileges for the customer to log in to the WSO2 products' Management Consoles. 

Vulnerability assessment testing.

Penetration testing (WSO2 will outsource to third-party consultants).

Guarantee the availability of the Managed Cloud (See Support and Maintenance).WSO2 product training.
Upgrade WSO2 product and install patches upon request. 

Implement monitoring and alerting

WSO2  hosts all monitoring services in a separate subnet in the same VPC where the customer's Cloud services are hosted. We configure Nagios Remote Plugin Executor (NRPE) in all Linux hosts to monitor the resource utilization and set thresholds. If any resource gets utilized beyond a threshold, or if an application isn’t responding properly, NRPE triggers alerts and notifications. 

We collect statistics about resource utilization (i.e., disk, CPU and memory utilization, JVM heap usage etc.) and application health. All statistics collected via the NRPE agents are presented using ICinga, the monitoring and dashboard tool. We also configure all Linux hosts with Simple Network Management Protocol (SNMP) and host the statistics that are collected via SNMP using Cacti, the network graphing solution. All statistical dashboards are exposed only to the WSO2 network over HTTP/S. To communicate with the third-party services required to extend alerts, all monitoring hosts need to have Internet connectivity. However, this doesn't mean that the monitoring hosts are placed in the public subnet.

WSO2 requires an email server with SMTP Authentication enabled to send direct email alerts and notifications to other servers. If the customer cannot provide an email server, WSO2 uses Amazon Simple Email Service (SES). We need support from the customer to verify the domain and set up DomainKeys Identified Mail (DKIM), which is an email validation system designed to detect email spoofing. 

We maintain application logs using the LogstashElasticSearch and Kibana solutions. WSO2 configures a Logstash agent in each host to collect application data and send over to ElasticSearch that is running on the monitoring host in a different subnet in the same VPC. The Kibana dashboard is exposed only to the WSO2 network over HTTP/S.

The monitoring and alerting implementation is depicted in the diagram below:


If the customer wants to synchronize their monitoring with that of WSO2, DevOps teams from both sides need to agree on certain technical requirements such as additional agents that must be installed on hosts, how to expose dashboards to other networks, send alerts to additional email addresses and phones etc. 

Implement backup and disaster recovery 

A disaster is a failure of the system that cannot be recovered using its own resources. To recover the system in case of a disaster, WSO2 maintains the necessary backups and scripts in a geographically separate location and sets up a replica of the live system in that location. 

All backup WSO2 processes are automated.

  • Backups are taken of hosted artifacts such as web applications and services, application and system logs, and databases related to the solution, including WSO2 product databases.
  • Backup frequency is daily by default, but this can change after a discussion with the customer regarding the size of the data and the frequency that the data changes.
  • The customer can request log and artifact backups anytime, and the backups up to the last three months are given. 
  • Database backups cannot be provided immediately upon the customer's request as the database backups are stored in an Amazon-native way. Getting the backup might take some time.
  • Artifact and log backups are stored in AWS and can be archived to Amazon Glacier upon the customer's request.
  • Database backups are taken as Amazon RDS snapshots. 
  • If there are Elastic Block Storage (EBS) volumes in the deployment, snapshots will be taken daily, using the AWS-provided snapshot feature.

Commit the artifacts

WSO2 manages a subversion repository internally to store and manage resources such as scripts, documents, diagrams regarding the Managed Cloud. WSO2 ensures that they are secure and not publicly accessible to anyone. WSO2 shares these resources with the customer upon his/her request.

Also, once the customer deploys any kind of application or service artifact to a WSO2 server in the Managed Cloud, WSO2 takes ownership and responsibility of its security and availability.

Hand over the environments

WSO2 is to hand over the production environment to the customer with:

  • URLs of the WSO2 products deployed in the Managed Cloud.
  • Credentials with admin privileges to access the Management Consoles of the WSO2 products.

Tip: Note that WSO2 can facilitate the following upon the customer's request:

  • Arrange a third-party consultant to carry out penetration tests.
  • Provide reports and dashboards on the production environment.
  • Arrange trainings and workshops for the customer.
  • Provide read-only access to the monitoring dashboards and the log viewer.

Next, go to Support and Maintenance.

  • No labels