3. Small Scale Enterprise Systems¶
3.1. System Scenario¶
This document describes exemplary solution implementations for a “Small Scale Enterprise System” scenario. Small 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. (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¶
The main site accommodates the enterprise system during normal operation times, and configurations similar to the following can be assumed.
- 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.
Below is a diagram outlining the system configuration.
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.
For example, with Microsoft SQL Server, generally there are restrictions for usage within a shared environment. VMs of Virtual Server can run on shared platforms, but as Service Provider is a Microsoft “Authorized Mobility Partner”, License Mobility through SA (i.e., Software Assurance) benefits can be utilized. Specifically, Microsoft SQL Server licenses can be carried over and utilized in following instances:
- 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.
Volume (internal disk) performance may be insufficient in the enterprise production environment. In this case, high speed Volume will be provided from Block Storage Service as an external disk so as to mount and be utilized as data storage.
3.2.1.3. Database Backup¶
Database backup that is prepared for logical and physical failures is important even though the system is small-scale.
In this example, a VM set as a file server for backup purposes (as in backup server) is combined and built with block storage. Backup files for full/differential backups and transaction logs are expected to be output to the backup server in scenario, utilizing DBMS backup commands and tools (SQL Server Management Studio etc.). Virtual Server (Instance and Volume) provided by Virtual Server can be assigned to an equipment group (AZ: Availability Zone) for storage. For example, by configuring a DB server to Zone A and a backup server to Zone B, a simultaneous service outage can be avoided in the event that either server experiences a physical failure.
3.2.1.4. Utilizing RDS User CAL BYOL¶
When building a Windows Server Remote Desktop environment on a shared platform, RDS (Remote Desktop Service) access licenses are required. With this service, license mobility benefits can be utilized by adding SA (Software Assurance) for the Customers’s RDS User CAL (Client Access License). Specifically, RDS User CAL can be carried over and utilized in the cloud environment by the following procedure.
- 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¶
In many cases, even small scale enterprise systems have testing and development environments prepared in addition to the production environment.
For Virtual Server , billing can be reduced by setting an Instance to a suspended status whilst keeping it not in use, in comparison to continuously operated in running status. As an method of further reducing costs, Instance and licensing service billing can be suspended by deleting the Instance, leaving only the volume, and creating an image inside the volume. However, tasks such as launching an instance and attaching the volume are required for booting the server, which can be time consuming for deployment.
Operations can be implemented balancing cost and time according to the usage frequency of the testing/development server.
3.2.2. DR Site Configuration¶
It will be necessary for the system to switch over to the DR site should a disaster occur at the main site.As a long RTO is allowable in this case, the goal of this example is to prepare a DR site with a low maintenance cost. Therefore, the model will allow ease of rebuild and data recovery during a disaster, without a regularly running instance at the DR site.
Below is a diagram outlining the system configuration.
The main points of the configuration are described in the following sections.
3.2.2.1. Hot / Cold Standby(s) DR Site Servers¶
Each server type will be built at the DR site and set to stand by.
For example, servers with features that require constant syncing, such as AD servers, will also be in running status at the DR site and will require replication from the main site (that is called a “hot standby”). Usage of Remote Inter-DC Network Connectivity is recommended for traffic for replication between sites. As the Remote Inter-DC Network Connectivity service between DCs and can be utilized free of charge, DR costs can be reduced.
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¶
Once DR measures are initiated, the newest data will not be reflected to the DR site database server data. There, in addition to recovery from full/differential backup data, roll forward processes are carried out using transaction logs which shortens RPO.
First, as a normal backup, full/differential backups and transaction logs should be routinely obtained from the main site backup server. This data should be routinely copied to the DR site from the main site through the 10Gbps networks between DCs. Through this, the newest backup data can always be available at the DR site.
During disaster recovery, a restore can be performed for the standby database server from the full/differential backups. Through roll forward processes using transaction logs for data outside the full/differential backups, recovery up to the latest status will be achieved.
3.2.2.3. Switching Over User Access Paths¶
When migration and restore processes are completed for data at the DR site, it will be necessary for to switch access paths for users. Especially for Enterprise system where accessing through VPN in user scenario, VPN access path should be required to be changed accordingly without any difficulties. For such switch-overs, there are two (2) patterns for Customers to utilize as below:
- 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.
Furthermore, Internet transmissions and 10Mbps Menu (at Best Effort) should be either free of charge or if ever charged that will be less than market price, so such can be utilized without much of financial burdens on the end of Customers, so the Internet connectivity beforehand is required. Moreover, Customers can ensure their global IP Addresses (these are commercially priced, so it is not really free) with parameters including global IP Addresses. By doing so, Customers can create such switch-over procedures much easier and simpler orders when the disaster recovery does occur in real time.