3. Small Scale Enterprise Systems¶
3.1. System Scenario¶
- Normal operation is available for 24 hours of 365 days a year. (Service outages are acceptable during maintenance periods.)
- It is preferable if SPOF (i.e., Single Point of Failure) is not allowed, but on the premise that server redundant HA (i.e., High Availability) configuration is assumed on the virtual environment.
- RPO (Recovery Point Objective) can be up to approx. one (1) day. (In case it is within 1 day, the archive log will be backed up several times a day to be able to execute roll forward recovery.)
- As this is a critical system to some extent, the RTO (Recovery Time Objective) may include DR (disaster Recovery) measurements for evacuating full data backup and a system rebuild to be performed after disaster recovery.
3.2. System Configuration¶
This system, assuming implementation of DR 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.
3.2.1. Main Site Configuration¶
- All servers are configured on a low-cost shared virtual platform.
- The RD (i.e., Remote Desktop Gateways), which is accessed via the Internet by outside users, is configured within the DMZ segments.
- Three-way planes in terms of configurations; i.e., production, testing, and development environments.
The main points of the configuration are described in the following sections.
3.2.1.1. Utilizing BYOL Database License¶
Database software such as Microsoft SQL Server and Oracle DB are not included in the standard templates provided by the Virtual Server service. As such, it is necessary to carry over and utilized the licenses purchased by the Customers in order to build a database on a Virtual Server VM.
Note
Customers are advised to follow license and technical restrictions/requirements determined by each software type regarding ability to carry over software licenses to the cloud environment.
- The Customers who purchase a Microsoft SQL Server volume license from a Microsoft resale partner.
- The Customers who add a contract for SA (Software Assurance) for the above-mentioned volume license.
- The Customers whose Microsoft SQL Server volume license is carried over (or brought in as in BYOL) to the Virtual Server server based on License Mobility through SA (Software Assurance) benefits.
- Customers are noted that the “License Verification Form” is to be completed within 10 days since BYOL is carried in, and submitted to Microsoft via the resale partner.
Note
This service does not provide Microsoft SQL Server licenses based on SPLA (i.e.,Services Provider License Agreement).
Note
Customers are noted here that BYOL Oracle products brought in to run Virtual Server is not supported. For cases of carry-over of Oracle products, therefore, Customers are recommended that they utilize Baremetal servers.
3.2.1.2. Storage for Database Data Space¶
Virtual Server has volumes (internal disks) attached for system storage. In this example, VM volumes (internal disks) are added and attached for usage as storage for database data storage.
3.2.1.3. Database Backup¶
3.2.1.4. Utilizing RDS User CAL BYOL¶
- The Customers purchases a RDS User CAL volume license from a Microsoft resale partner.
- The Customers adds a contract for SA (Software Assurance) for the above-mentioned volume license.
- The Customers’s RDS User CAL is carried over to the Virtual Server server based on “RDS User Client Access License (CAL) - Extended Rights” through SA (Software Assurance) benefits.
- The “License Verification Form” is completed within 10 days of the carry-over, and submitted to Microsoft via the resale partner.
Note
This service does not provide RDS SAL (i.e., Subscription Access License) based on SPLA (i.e., Services Provider License Agreement).
3.2.1.5. Enterprise Production/Testing/Development Environment Configuration and Low Cost Line¶
3.2.2. DR Site Configuration¶
The main points of the configuration are described in the following sections.
3.2.2.1. Hot / Cold Standby(s) DR Site Servers¶
Servers that don’t require replication are built at the DR site and set to a suspended status (cold standby). Cost can be cut back due to the inexpensive charge for instance billing based on suspension status being applied while in this state.
Note
When performing maintenance tasks such as server patching, it is recommended to perform the same tasks on the DR site standby servers, not only the main site production servers.
Furthermore, as previously mentioned, there is also the method of deleting the instance and leaving only the Volume and Volume Image. In this case, cost can be suppressed, but tasks for deployment of the server may be time consuming. A suitable method should be selected that matches the server’s purpose, as well as RTO and cost requirements.
3.2.2.2. Database Backup Copying Between Sites¶
3.2.2.3. Switching Over User Access Paths¶
- 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.