Daftar isi
Servers
The VPC is divided into two zones, which are hosted in different physical locations. Further, there are two subnets. The public subnet contains servers that (through the NAT) are able to be accessed from outside the VPC (web and messaging servers). The private subnet contains servers that can only be accessed from within the VPC (database, processing and reporting servers).
All iSIKHNAS servers are listed here. They are identified by their location (zone 1 or zone 2, indicating the two physical locations), subnet (private or public), their | instance type(indicating memory and CPU capacity) and whether they are autoscaling (elastic) or not. Load balancers are used to distribute requests to autoscaling servers.
Network Address Translation (NAT) server
This is the only point of access to the VPC. It is a single instance (non-elastic) and is located in Zone 1, public subnet. Its sole role is to manage security and direct incoming traffic to the correct server in the VPC.
Type: m1.small
Messaging server
This is in the public subnet of zone 1 and is a single instance. It is responsible for sending and receiving e-mail, managing the SMS system and managing Instant messaging.
Type:m3.medium
E-mail processing
In addition to an email server, it uses email aliases to direct incoming email to the email parsing scipt (Python). This checks that the sender is authorised, and saves any Excel attachments to an S3 bucket (com.isikhnas.queuefiles). It then puts a message on the emailinput queue for processing by the processing server.
Outgoing email is managed by a Python daemon, listening on the emailoutput queue, and getting attachments from the com.isikhnas.emailattachments bucket.
SMS processing
SMS messages are managed by SMSTools3. Incoming messages are parsed and submitted to the master database, which is then checked for any response messages.
Instant messaging
IM is managed by a Python daemon which listens for incoming messages, submits them to the database, and checks for outgoing responses in the same way as the SMS sytem. In addition, if an incoming message contains a link to an image, the image is saved to an S3 bucket (static.isikhnas.com/images), and the message is recoded as an IMAGE message to store the file name and attach it to a case record.
Processing server
This is an elastic instance located in the private subnet. The main instance is located in Zone 1, but elastic instances are created so as to balance the numbers between zones 1 and 2.
This server processes incoming email Excel attachments, parsing their contents and inserting them into the database. It gets request from the emailinput queue, and gets attachments from the com.isikhnas.queuefiles bucket. Once processed, it puts request to send email responses on the emailoutput queue, and any attachments for the email in the com.isikhnas.emailattachments bucket.
This server has a Python daemon listening for messages on the emailinput queue.
Type: m3.medium
Reporting server
This is an elastic instance located in the private subnet. The main instance is located in Zone 1, but elastic instances are created so as to balance the numbers between zones 1 and 2.
This server generates output reports, including regular e-mail reports (daily, weekly, monthly), and ad hoc reports based on templates (for example client reports after laboratory submissions).
Regular reports are generated by a Python script triggered by a cron job. Ad hoc reports are produced by a daemon listing on the reportrequest queue. Completed reports are stored in the reports.isikhnas.com S3 bucket and email request placed on the outgoing email queue.
Type: m3.medium
Database servers
Master database server
There is a single instance of the master database server located in the private subnet of zone 1. This handles all database requests that require writing of data, and is accessible only from within the VPC.
Type: m3.medium
Slave (read-replicate) database servers
This is an elastic group of servers in the private subnet, balanced bewteen zones 1 and 2. These servers play a triple role:
- real time backup
- automated promotion to master in case of failure
- read-access
- any reporting or analysis process that requires only read access to the database is directed to one of the read-replicas. This minimises load on the master database to maximise performance. This is necessary as some of the output reports require extensive and complex database processing, which would otherwise slow down the master database for other requests.
Type: m3.large
Training server
The training server (Sidecar) is completely independent from the VPC, and contains a duplicate database, web site and SMS messaging system. The database is automatically updated from the live database every Monday morning, and updates to the user and infrastructure tables (only) on the live server are instantly copied to Sidecar.
Email and Instant messaging requests for the training server are handled by the messaging server, which direct the requests to the Sidecar database.
Type: m3.medium
Wiki server
This is a self-contained documentation server located in the VPC public subnet in zone 1. It runs MediaWiki and a MySQL database. To increase performance during CPU intensive processes (particularly when exporting content to ODT or PDF format), there is a separate Wiki rendering server dedicated to that role.
Type: m3.medium and T2.small (renderer)