Views

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

The Wiki of Unify contains information on clients and devices, communications systems and unified communications. - Unify GmbH & Co. KG is a Trademark Licensee of Siemens AG.

Jump to: navigation, search
Line 1: Line 1:
 
 
{{Breadcrumb}}
 
 
[[File:DLSclient-sample-screen.jpg|250px|thumb|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|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 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.

Revision as of 13:34, 5 November 2014

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.