IT:Servers: Perbedaan revisi
(→Servers) |
|||
| (3 revisi antara oleh 2 pengguna tidak ditampilkan) | |||
| Baris 1: | Baris 1: | ||
| − | =Servers= | + | <languages/> |
| + | <translate> | ||
| + | =Servers= <!--T:1--> | ||
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). | 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). | ||
| + | <!--T:2--> | ||
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 [http://aws.amazon.com/ec2/instance-types 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. | 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 [http://aws.amazon.com/ec2/instance-types 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== | + | ==Network Address Translation (NAT) server== <!--T:3--> |
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. | 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. | ||
| + | <!--T:4--> | ||
Type: m1.small | Type: m1.small | ||
| − | ==Messaging server== | + | ==Messaging server== <!--T:5--> |
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. | 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. | ||
| + | <!--T:6--> | ||
Type:m3.medium | Type:m3.medium | ||
| − | =====E-mail processing===== | + | =====E-mail processing===== <!--T:7--> |
| − | In addition to an email server, it uses email aliases to direct incoming email to the email parsing | + | In addition to an email server, it uses email aliases to direct incoming email to the email parsing script (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. | + | <!--T:8--> |
| + | 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 processing===== <!--T:9--> |
SMS messages are managed by SMSTools3. Incoming messages are parsed and submitted to the master database, which is then checked for any response messages. | 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===== | + | =====Instant messaging===== <!--T:10--> |
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. | 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. | 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== | + | ==Processing server== <!--T:11--> |
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 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. | ||
| + | <!--T:12--> | ||
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 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. | ||
| + | <!--T:13--> | ||
This server has a Python daemon listening for messages on the emailinput queue. | This server has a Python daemon listening for messages on the emailinput queue. | ||
| + | <!--T:14--> | ||
Type: m3.medium | Type: m3.medium | ||
| − | ==Reporting server== | + | ==Reporting server== <!--T:15--> |
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 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. | ||
| + | <!--T:16--> | ||
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). | 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). | ||
| + | <!--T:17--> | ||
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. | 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. | ||
| + | <!--T:18--> | ||
Type: m3.medium | Type: m3.medium | ||
| − | ==Database servers== | + | ==Web servers== <!--T:19--> |
| + | These are elastic instance located in the public submit. The main instance is located in Zone 1, but elastic instances are created so as to balance the numbers between zones 1 and 2. | ||
| + | |||
| + | <!--T:20--> | ||
| + | These servers provide the iSIKHNAS web site. | ||
| + | |||
| + | <!--T:21--> | ||
| + | Type: m3.medium | ||
| + | |||
| + | ==Database servers== <!--T:22--> | ||
=====Master database server===== | =====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. | 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. | ||
| + | <!--T:23--> | ||
Type: m3.medium | Type: m3.medium | ||
| − | =====Slave (read-replicate) database servers===== | + | =====Slave (read-replicate) database servers===== <!--T:24--> |
This is an elastic group of servers in the private subnet, balanced bewteen zones 1 and 2. These servers play a triple role: | 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 | * real time backup | ||
| Baris 57: | Baris 79: | ||
** 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. | ** 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. | ||
| + | <!--T:25--> | ||
Type: m3.large | Type: m3.large | ||
| − | ==Training server== | + | ==Training server== <!--T:26--> |
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. | 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. | ||
| + | <!--T:27--> | ||
Email and Instant messaging requests for the training server are handled by the messaging server, which direct the requests to the Sidecar database. | Email and Instant messaging requests for the training server are handled by the messaging server, which direct the requests to the Sidecar database. | ||
| + | <!--T:28--> | ||
Type: m3.medium | Type: m3.medium | ||
| − | ==Wiki server== | + | ==Wiki server== <!--T:29--> |
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. | 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. | ||
| + | <!--T:30--> | ||
Type: m3.medium and T2.small (renderer) | Type: m3.medium and T2.small (renderer) | ||
| + | </translate> | ||
Revisi terkini pada 22 Juni 2018 16.56
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 script (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
Web servers
These are elastic instance located in the public submit. The main instance is located in Zone 1, but elastic instances are created so as to balance the numbers between zones 1 and 2.
These servers provide the iSIKHNAS web site.
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)