2. Medium Scale Enterprise Systems¶
2.1. System Scenario¶
This document describes exemplary solution implementations for a “Medium Scale Enterprise System” scenario. Medium scale enterprise systems mainly fall under the categories of “Business Systems” and “Finance and Accounting Systems” for internal company users, and are applied to systems with the following features.
- Normal operation is available for 24 hours of 365 days a year, and is basically performed by one-by-one fall back. (Except in redundant configuration related maintenance where suspension of all servers is required.)
- SPOF (i.e., Single Point of Failure) is not allowable. (Requires physical separation will be prescribed for redundant configuration.)
- RPO (i.e., Recovery Point Objective) is so implemented at a set goal with 0. (For special failures, such as loss of REDO log space, returns to the time of backup in units of several hours.)
- As this is a critical system, requires DR (i.e., Disaster-Recovery) measurements for employees in separate locations to be able to utilize even in disaster.
2.2. System Configuration¶
This system scenario places DR measures to be configured from the two (2) locations which are distant from one another in between the Main Site and DR Site. In the following description, Customers will receive two (2) system configurations: Main Site System Configuration and DR Site System Configuration.
2.2.1. Main Site Configuration¶
- Server system configuration allowing Web-AP/DB servers to coexist on 1 Virtual Server.
- Production/Testing/Development environment operation, including additional creation of testing configurations as necessary.
- Archive storage for long-term data storage.
- In order to obtain sufficient processing time for nightly batches, the database utilizes storage functionality so they complete backup processes within few minutes.
The main points of the configuration are described in the following sections.
2.2.1.1. DBMS Configuration¶
Note
It is required for Customers to perform design, build, and operations tasks for virtual platforms such as Hyper-Visor (ESXi etc.) and servers for management (vCenter etc.). Additionally, the Customer is required for procurement/management of software licenses for the Guest OS, middleware, and applications etc. running on the Virtual Server.
2.2.1.2. Database Storage Configuration¶
Note
Once a LUN has been configured, its volume cannot be expanded. For example, a LUN created at 100GB cannot be later expanded to 250 GB.
Note
The REDO log file requires storage performance. Depending on the log file size, LUN sizing consideration will be necessary not only to volume requirements, but also performance requirements.
2.2.1.3. Testing Environment Build and Production Data Replication¶
System space and AP module can be replicated on the testing environment by utilizing production environment Baremetal server’s cloning functions and / or Virtual Server Service functions for imaging of internal disks for data storage.
2.2.1.4. Archive Data Storage¶
Note
Cloudn Object Storage、Biz Simple Disk are all available only within domestic Japan.
2.3. DR Site Configuration¶
The main points of the configuration are described in the following sections.
Note
Volume images cannot be exported in cases where the software license service is associated with the volume image.
VM running in operation on a Baremetal Server is able to utilize DR solutions provided by the virtual platform. Through this, VM protection can be implemented for those running on the Baremetal Server. For example, in the vSphere environment Hyper-Visor-level replication between DCs can be implemented using vSphere replication.
Note
Block storage configure for DataStore does not have a LUN snapshot transfer function. As such, storage array based replication for VMware vCenter SRM (i.e., Site Recovery Manager) is not supported.
Note
Customers are required to design, build, and operations tasks for Site Recovery with the virtual environment configured over Baremetal Server.
Web-AP/DB server data storage is stored on the block storage LUN. DR measures can be implemented by always syncing this DB storage space (using Oracle Data Guard etc.) between main site and DR site Web-AP/DB servers. The 10Gbps networks between DCs can be utilized free of charge for forwarding of traffic for syncing.
Note
Cloudn Object Storage、Biz Simple Disk are all available only within domestic Japan.
- By regularly designating private IP Addresses anew to respective nodes on the DR Site, VPN should be connected from the beginning. At the time of DR, internally utilized DNS record will be modified and user connection will be switched over safely from main site to recovery site. With switching over private IP Addresses to ensure such actions, DR Zone files and change scripts should be prepared beforehand regularly as daily routines, which will let Customers proceed much more smoothly.
- In the other patterns, the replica configuration is deployed by Customer, preparing for such event as DR even prior to such will occur; therefore, Customers can smoothly switch over to the other side by designating private IP Addresses on DR site (just as service will) with the main site service. At this point, difficulty on system transmissions as route is not clarified on DR site, so such actions will not arise any risks even though concurrent IP Addresses are designated on both of DR and Main Sites. At the time of disaster or abnormal failures on Main Site, the well-prepared API will be utilized and that will open the route, which will guide DR Site’s new-coming transmissions.