6. Medium Scale External-Facing Systems¶
6.1. System Scenario¶
- Operation time is led with the premise that it basically is required to be 24/7. Short-term service outages should be minimal.
- Web servers and AP servers are configured for load-balancing.
- Customers can utilizes DBMS Testing Version of mySQL etc with no charge.
- In order to lower workload, DB servers’ master + lead-only replication + backup replication will be multiply configured.
- DB servers require high IOPS disks and high response processing.
- Supports https transmissions (SSL termination point function).
- Supports linkage with other systems, sending/receiving external email, and mass mailing (email magazine) services.
- Requires linkage with CDN when the access is heavy-laden.
6.2. System Configuration¶
This system, assuming implementation of DR (Disaster Recovery) measures, is configured from 2 geographically separate sites: the main site and the DR site. The system configurations for the main site and the DR site are described below.
6.2.1. Main Site Configuration¶
- Site protection utilizing UTM.
- Physically distributed configuration of application servers and scale-out that responds to workload changes.
- Configuration of multiple MySQL replication servers guaranteed by physical distribution.
- Backup configured utilizing a master DB and replication DB for backup.
The main points of the configuration are described in the following sections.
6.2.1.1. Secure Networks¶
The Internet Connectivity menu provided by this service includes installation of standard DDoS reduction devices. Additionally, unauthorized access from external networks can be detected and prevented by setting up UTM which provides IPS/IDS functions inline between the FW and LB. Through this, a secure network environment can be built and the site can be effectively protected.
6.2.1.2. Configuration and Scale Out of Physically Separated Web/AP Servers¶
6.2.1.3. Physically Separated DB Servers¶
In this example DB workload distribution can be implemented using a MySQL replication configuration. Similar to Web/AP servers, Virtual Servers (Instance + Volume) are physically divided LUNS of block storage into groups into master DB and replication as a certainty for storing DB data space will be configured into separate groups which can thereby increase failure support.
6.2.1.4. Database Backup¶
A backup processing replication instance will be created to keep down master DB workload and the replica for backup use LUN of block storage instance in a separate group. Through this, the actual replica will store data on physically separate storage. Additionally, backups can be performed to divide into two (2) physically different storage to store data; these physically different storage will be utilized even when performing data backup by mySQL dump etc. separated into multiple generations. |
6.2.1.5. Utilizing External Services¶
Note
Cloudn Object Storage、Biz Simple Disk will be dedicated within the domestic Japan.
6.2.2. DR Site Configuration¶
For systems that regularly update their database, such as external-facing e-commerce sites, it is difficult to implement a complete Act-Act DB at the DR site with configuration by network latency. As such, the DR configuration will take the form of asynchronous database replication to the DR site whilst utilizing remote Inter-DC Network connectivity . Automation of DB server monitoring, switching between master and replica, Web/AP server provisioning, and linkage to DNS switch etc. using API functions can be considered, but the expectation is that support will be implemented once the failure status is confirmed. This guide therefore includes DR implementation from installation of the replica through to launching Web/AP servers to a bootable status. | | Below is a diagram outlining the system configuration.
The main points of the configuration are described in the following sections.
6.2.2.1. Database Replica Utilizing Remote Inter-DC Network and NFS Server’s Common Contents Replica¶
Customers can connect their network through to Remote Inter-DC Network as gateways at a location where the Customers so wish; therefore, they can connect it to segment(s) for DB replication and utilize it by replicating as a DR site. In order for Customers to provide troubleshooting for MySQL replicating functions’ failures / errors, Customers are noted here that they can transfer back file output of main site to DR site. In case there is NFS Server is setup to locate common contents for Web server, Customers are advised that they can enable synchronizing it with DR site through rsync, etc. via remote Inter-DC Network.