6. Medium Scale External-Facing Systems¶

6.1. System Scenario¶

This document describes exemplary solution implementations for a “Medium Scale Enterprise System” scenario. In this scenario system utilizing to devise communications with Customers and such online through Web and E-Commerce Sites with following features:

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¶

The main site accommodates the production system during normal operation times, and configurations similar to the following can be assumed. (However, development/verification platform environment is omitted for the purpose of concise description here)/検証用環境は省略しています）

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.

Below is a diagram outlining the system configuration.

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¶

In order to process large volumes of traffic from the end user, multiple Web/AP servers will be installed and load distribution as well as redundancy will be achieved using the LB. Here, Virtual Servers (Instance + Volume) are used to build Web/AP servers. However, in cases where virtual servers are stored on the same device, there is a possibility that all virtual servers will go offline simultaneously with a physical failure. In preparing against this type of risk, virtual servers will be setup and distributed into separate groups. Through this, Web/AP servers can take a physically redundant configuration.

Furthermore, as a characteristic of e-commerce sites, an influx of access leading to sudden workload increases must be considered. In cases where several Web/AP servers are increased and decreased frequently, OS templates that are no charge toward virtual server subscribers, CentOS and such are prepared so that there is little cost from a license standpoint. Implementation of these increases /decreases according to workload generation will be supported by virtual server scale out. Firstly preparatory task is required for Customers to configure in virtual server to create a template of the Web/AP server. Afterwards, the virtual server workload should be routinely monitored and when a large workload increase is detected then Web/AP servers should be added using the template that was created previously. Whilst monitoring an additional virtual server can be added and then performed via API, the sequential tasks can be automated as necessary.

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¶

Services provided by Service Provider can be combined to web systems.
For example, an external DNS server Cloudn build becomes unnecessary by utilizing the DNS service, and Internet traffic and web server workload can be reduced by utilizing CDN. Furthermore, overall system reliability can be improved through combined usage of the services that are operated with high reliability by a service provider.
Additionally, large volumes of logs can be stored at low cost by utilizing object storage for archive data. Cloudn Object Storage takes redundant configuration by implementing 3-way distributed data storage straddling multiple data centers achieving 99.999999999% (11 nines) reliability. As such data loss can be prevented even during site failure at the main site due to disaster.  Internet gateways can be built multiply, so that Customers can split evenly the number of Internet gateways that they will utilize for servicing access and for Cloudn Object Storage access.

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.

6.2.2.2. Low Cost DR Site Preparation¶

In order for Customers to keep DR site costs low, they can provision template uploaded so that they can provision at the time they utilize DR site. They can also configure chef and ansible and so forth in private template in which such are provisioned by preparing a script beforehand using API functions, actual tasks lead-time can be minimized. For Firewall, Native API / CLI are publicly provided for Customers to script the setting work, so that Customers can allow to provision whenever they are required to utilize the settings within a short time.

Internet connectivity can be kept contracted within the minimal bandwidth along with global IPs for DNS switch preparation; if in any case switch-over time will be allowed, then Firewall and Load Balancer and such are configured not to be connected at all, and Customers are able to provision via API at the launch of DR site. For the above configurations diagram, NFS Server and replication’s DB server will merely be constantly activated for the sync of contents.

5. Internet Gateway and Related Systems

7. Multi Cloud Management