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

This is what we do in the implementation phase:

  • Set up remote access from WSO2 to your Amazon EC2 instances. See Managing Remote Access.
  • Set up the environments (e.g., Development, Test, Pre-Production, and Production).
  • Implement monitoring and alerting. See Implementing Monitoring and Alerting for details.
  • Implement backup and disaster recovery.
  • Commit all scripts, diagrams, and documents to the repository for versioning and history.

Note that WSO2 can facilitate the following upon your request:

  • Arrange a third-party consultant to carry out penetration tests.
  • Reports and dashboards on the Production environment.

Managing remote access

WSO2 recommends you to do 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.

To set up your Cloud environments, WSO2 requires access to your Amazon EC2 instances. We access these 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. The diagrams below depict both scenarios.

Bastian host in the VPC

The 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.

<image>

Bastian host in your datacenter

The 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.

<image>

In addition to the AWS instances, WSO2 requires access to the following resources:

Need access toPurposePrerequisites
AWS management consoleTo access and manage your AWS.

WSO2 needs separate user accounts with the following form you:

  • AWS account ID.

  • AWS IAM user with admin privileges for VPC, EC2, RDS, S3, SES and Route53 services.

  • IAM user with admin console access.

  • MFA enabled for the user accounts as well as the root account.

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 VPC, EC2, RDS and S3.

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

Implementing monitoring and alerting

WSO2 hosts all monitoring services in a separate subnet in the same VPC where your Cloud services are hosted. We collect statistics about the following:

  • System resource utilization (disk, CPU and memory utilization, JVM heap usage etc.)

  • Application health.

 

WSO2 configures Nagios Remote Plugin Executor (NRPE) in all Linux hosts to monitor the resource utilization and set thresholds. If any resource gets utilized beyond a certain threshold, or if an application isn’t responding properly, NRPE triggers alerts and notifications. All statistics collected via NRPE agents are presented using ICinga, the monitoring and dashboard tool. The statistical dashboard is exposed only to the WSO2 network over HTTP/S. 

We also configure all Linux hosts with SNMP and host the statistics that are collected via SNMP using Cacti, the the network graphing solution. The statistical dashboard is exposed to the WSO2 network over HTTP/S. 

 All monitoring hosts need to have Internet connectivity to communicate with any required third-party services to extend alerts, but the monitoring hosts are not placed in the public subnet.

 WSO2 requires an email server with SMTP Auth enabled to send direct email alerts and notifications to other servers. If the customer cannot provide an email server, WSO2 uses Amazon SES. We need support from the customer to verify the domain and set up the DomainKeys Identified Mail (DKIM), which is an email validation system designed to detect email spoofing. As part of ICinga installation, a local email server is set up. The WSO2 DevOps team configures this server to relay emails to a known email server that resides within or outside the AWS infrastructure.



 

 

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

 



Next, go to Handover.

  • No labels