Difference between revisions of "How to setup a synchronously Mirrored Database"

Revision as of 13:33, 5 November 2014

You are here:

Home  How to setup a synchronously Mirrored Database

Deployment Service client screenshot

The Deployment Service (DLS) is a stand-alone Unify management application for central administration of the following IP Devices (both SIP and HFA) in VoIP networks:

• IP Phones:
  • OpenScape Desk Phone IP
  • OpenStage
  • optiPoint 410/420 (all versions)
  • optiPoint WL2 professional
  • OpenScape Personal Edition
  • optiClient 130

• IP Gateways and HiPath/OpenScape platforms:
  • HiPath 4000 V5 and V6,
  • HiPath 3000 (through HG1500) V8 and V9,
  • OpenScape Office MX/LX V3 (subject to a Project Specific Release),
  • OpenScape Voice V5, V6 and V7

DLS is the central component with which devices and QoS parameters of IP devices are administered for the customer's entire OpenScape/HiPath or non HiPath solution.

The latest released version is OpenScape Deployment Service V7 R2 (CV432).

The OpenScape DLS is designed as a client/server application.

The client (DLS-GUI: Graphical User Interface) is written in Java and requires a standard web browser and JRE as Java runtime engine.

The server is also written in Java.

Two DLS server variants are available:

• DLS as standalone installation on MS Windows Server 2008 R2 / 2012 Standard & Enterprise Edition (64-bit);

• DLS installed on-oboard on an OpenScape Voice platform (DLS is delivered with OpenScape Voice Assistant DVD application package).

In addition to standard DLS-GUI based operation, most DLS functions can also be operated by external applications over a web service interface, the DlsAPI.

In order to guarantee maximum resilience, it is possible to deploy two separate database servers. At this, only one database server is connected to the DLS(single node or cluster), while the data are mirrored on the other server.

In case the main server ("Principal") fails, the second server ("Mirror") assumes its function.

For database mirroring, two models are supported:

• Synchronous Mirroring: A third server ("Witness") monitors the state of the main server. If the Principal should fail, the Witness will switch over to the Mirror, which will hereby become the Principal. Moreover, the Witness checks whether all transactions have been completed on the Mirror, too. Thus it is ensured that no data loss will occur. However, the performance will be slightly lower than with asynchronous mirroring. Be aware that High Availability with guaranteed data loss prevention is possible only with synchronous mirroring.

• Asynchronous Mirroring: There is no Witness, and the switchover to the mirror server is done by "Forced Service", i. e., by the DLS.

System Requirements

The following requirements must be fulfilled for database mirroring:

• Microsoft SQL Server Enterprise Edition with latest Service Packs is installed on all servers needed for database mirroring (Principal, Mirror and Witness, where applicable).

• Microsoft SQL Server Management Studio has to be installed.

• At least the first DLS node should be installed because mirroring can be set up only for a DLS database that has already been set up. This is part of the installation process for the first DLS node.

• The service DeploymentService is stopped on all participating DLS nodes.

• For the DLS database (DLSdb), the recovery model "Full" is set.

• The size for the TransactionLog is unlimited.

As the transaction log can reach any size, it might occur that the hard disk in use gets full, which would lead to SQL server and DLS failure. Thus, create a backup plan according to your requirements, and save the transaction log regularly, in addition to the DLS data. This effects a reduction of the currently active transaction log. Moreover, the transaction log should be saved significantly more frequent than the data proper, in order to keep the file as small as possible. When a database backup is performed, a complementary .trn file is generated. Those files are the backups of the transaction logs. This process makes sure that the transaction log-File "DLS_Log.LDF" does not grow endlessly. The very first creation of a .trn file might take considerably longer when a very large "DLS_Log.LDF" file has to be processed.  A DLS database restore does not require a correspondant .trn file. However, it is recommended to keep the latest transaction log file for investigation purposes in case a problem should occur.

The procedure

1. On the machine that is to be used as Principal, connect via Microsoft SQL Server Management Studio to the Database Engine. To connect to the DLS dB instance enter the following information:

* - Server Name: <Principal SQL Server name>\DLS

* - Authentication: Windows Authentication

2. Select DLSdb in Microsoft SQL Server Management Studio and configure Full Recovery model.

3. It is recommended to set an unlimited file size in the Files submenu by selecting unrestricted growth for DLSdb and DLSlog.

4. Enter the Witness and Mirror databases as you did in step 1. Create the "endpoints" for database mirroring by executing the following commands at the Principal server and the Mirror server:

* 2220 as TCP listener port

* PARTNER role

* Use Windows Authentication (WINDOWS NEGOTIATE)

5. Create the Witness Mirroring endpoint in the Witness server too.This endpoint should have the following characteristics:

* 2220 as TCP listener port

* WITNESS role

* Use Windows Authentication (WINDOWS NEGOTIATE)

6. Now, generate a backup of the DLS database on the Principal server under ’Share’ folder:

7. Prepare for database recovery at the Mirror server.Restore the files only of the db backup taken previously in the Principal server. In that way you get the logical and physical names of the backup files.

8. Using the filenames of the previous step, start the database recovery in Mirror \ DBData folder.

9. On the Principal, under ‘Share’ folder, generate a backup of the initial transaction protocol.

10. Subsequently, carry out the recovery of the transaction protocol in mirror.