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 49 Next »

This is what we do in the implementation phase:


Configure remote access. Set up remote access from WSO2 to your Amazon EC2 instances. 


Set up the environments (e.g., Development, Test, Pre-Production, and Production).


Implement monitoring and alerting.


Implement backup and disaster recovery.


Commit the artifacts such as scripts, diagrams, and documents to the repository for versioning and history.


Hand over the production environment to you with WSO2 Carbon user accounts that have admin privileges to access the Management Consoles.

Note that WSO2 can facilitate the following upon your request:

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

Configure remote access

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.


Need access toPurposePrerequisites
Amazon EC2 instancesTo set up the Cloud. 
AWS management consoleTo access and manage your AWS.

WSO2 needs separate user accounts with the following form you :

AWS API serviceTo execute automated tools to bring up the infrastructure services such as the VPC, network setup, databases etc.

WSO2 needs the following from you:

  • AWS IAM user with admin privileges for Amazon VPC, Amazon EC2, Amazon RDS and Amazon S3.

  • Access key and secret key generated for the same user.

Set up remote access to your Amazon EC2 instances

 We access your Amazon EC2 instances over SSH only, with a Bastion host working as the SSH gateway. The Bastian host can either reside in the VPC or in your own datacenter 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 your datacenterThe Bastion host is in your datacenter, 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 the environments

The WSO2 Managed Cloud offering is for hosting and maintaining WSO2 products in Amazon EC2 instances that you purchase. Here are the tasks performed by the WSO2 Managed Cloud team when setting up the environments. For additional services, you 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. 

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

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

Implement monitoring and alerting

WSO2  hosts all monitoring services in a separate subnet in the same VPC where your 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.

Implement an email system

Implement a domain name system

Implement time synchronisation with NTP


Implement backup and disaster recovery

<coming up soon>

Commit the artifacts

<Info about where the repository location is, what we mean by artifacts etc.>

WSO2 manages a subversion repository internally to store and manage resources such as scripts, documents, diagrams, etc. Upon request, wo2 will share these resources to the cstomer and make sure they are secure and not publicly accessilble.

Once customer deploys any kind of application or service artifact to a WSO2 server, WSO2 takes ownership and responsibility and make sure they are avaiobale for carbon server at all times.

Hand over the environments

WSO2 is to hand over the Production environment to you with WSO2 Carbon user accounts that have admin privileges to access the Management Consoles of all WSO2 products deployed in your Cloud.

<Can we come up with a check list of items that should be ready for hand over?>

Next, go to Support and Maintenance.

  • No labels