Documentation - Add docshare01.docshare.tips to …docshare01.docshare.tips/files/24603/246038920.pdfDocumentation HiPath 4000 V6 System Components - Software Service Documentation

Communication for the open minded

Siemens Enterprise Communicationswww.siemens-enterprise.com

DocumentationHiPath 4000 V6System Components - Software

Service Documentation

A31003-H3160-S102-4-7620

Our Quality and Environmental Management Sys-tems are implemented according to the require-ments of the ISO9001 and ISO14001 standard cer-tified by an external certification company.

Copyright © Siemens Enterprise Communications GmbH & Co. KG 2011Hofmannstr. 51, 80200 München

Siemens Enterprise Communications GmbH & Co. KG is a Trademark Licensee of Siemens AG

Reference No.: A31003-H3160-S102-4-7620

The information provided in this document contains merely general descriptions or characteristics of performance which in case of actual use do not always apply as described or which may change as a result of further development of the products. An obligation to provide the respective characteristics shall only exist if expressly agreed in the terms of contract. Availability and technical specifications are subject to change without notice. OpenScape, OpenStage and HiPath are registered trademarks of Siemens Enterprise Communications GmbH & Co. KG. All other company, brand, product and service names are trademarks or registered trademarks of their respective holders.

Siemens Enterprise Communicationswww.siemens-enterprise.com

Communication for the open minded

softwareTOC.fm

Nur für den internen GebrauchService Manual HiPath 4000 V6 - System Components - Software - Contents

Service Manual HiPath 4000 V6 - System Components -Software - Contents 0

1 Highlights and Hints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 HiPath 4000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1 HiPath 4000 in the Customer LAN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.1 LAN Interfaces for DSCXL2 Processors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.2 Checking the IP Addresses Used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.1.3 AP 3700 IP/HiPath 4000 SoftGate with Survivability Unit in the Customer LAN . . . . . . . . . . . . . . . . . . 8

2.2 Hardware Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3 Simplex/Duplex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3.1 Feature Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3.1.1 Simplex Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3.1.2 Duplex Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3.1.3 Separated Duplex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3.2 Service Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.3.3 High Availability Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3.3.1 Startup DSCXL2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.3.3.2 Failover Scenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3.4 Generation (Example). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.4 Supported Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.5 Corresponding Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.6 Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.7 Portlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.8 Applications, Loading Tables and Selections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.8.1 ADP/ADS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.8.1.1 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.8.1.2 Loading Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.8.1.3 Selections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.8.2 SWU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.8.2.1 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.8.2.2 Loading Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.9 Hardware Architecture Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.10 Hard Disk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.10.1 Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.10.2 Configuration Batch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.11 Smart Services Delivery Platform (SSDP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3 HiPath 4000 Assistant. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.1 HiPath 4000 Assistant Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.2 User Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.2.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.2.2 Customer Account Profiles for HiPath 4000 Assistant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.3 Notification Mechanism and Usage Scenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.3.1 The Notification Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.3.1.1 Operation of the Notification Mechanism. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.3.1.2 AMO Commands Generated for Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.3.1.3 Possible Sources of AMO Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

A31003-H3160-S102-4-7620, 04/2011HiPath 4000 V6, Systemkomponenten - Software, Service Documentation 3

Service Manual HiPath 4000 V6 - System Components - Software - ContentsNur für den internen Gebrauch

softwareTOC.fm

3.3.2 Networks without HiPath 4000 Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.3.3 Networks with HiPath 4000 Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4 HiPath 4000 CSTA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435 Installation and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.1 General Notes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.2 Available Deployments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.3 Suse Linux Enterprise Server Operating System Software Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.4 First Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

6 Time Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476.1 Configuring the Time on the HiPath 4000 Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476.2 Configuring the Time on all Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496.3 Configuring the Time Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6.3.1 Setting the Time Zone and Summer Time for HiPath 4000 Assistant and RMX. . . . . . . . . . . . . . . . . 496.3.2 Setting the Time Zone and Summer Time on the Access Point/HiPath 4000 SoftGate . . . . . . . . . . . 506.3.3 Setting the Time Zone for HiPath 4000 CSTA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

7 System Backup and Restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537.1 Feature Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537.2 Service Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547.3 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547.4 System Backup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547.5 System Restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

7.5.1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567.5.2 System Restore Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

7.5.2.1 Restore on the same unchanged Target System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567.5.2.2 Restore on the same Target System after new SLES Installation . . . . . . . . . . . . . . . . . . . . . . . . 577.5.2.3 Restore on the same Target System after LAN Card Changes . . . . . . . . . . . . . . . . . . . . . . . . . . 577.5.2.4 Restore on a different Target System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

7.5.3 System Restore via First Install Wizard (FIW). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587.5.4 eth Interface Configuration with LAN Wizard (HiPath 4000 Administration Portal) . . . . . . . . . . . . . . . 597.5.5 Provide License File for the CLA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

8 Raid Synchronisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 638.1 Leistungsmerkmalbeschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 638.2 Ablauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

9 Notfall-Festplatte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679.1 Erstellen einer Notfall-Festplatte. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

9.1.1 Voraussetzungen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679.1.2 Ablauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679.1.3 Fehlersuche. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

9.2 Einsatz der Notfall-Festplatte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

A31003-H3160-S102-4-7620, 04/20114 HiPath 4000 V6, Systemkomponenten - Software, Service Documentation

_highlights_hinweise.fm

Highlights and Hints

1 Highlights and HintsIssue 03

Rebranding OpenScape 4000 V6 -> HiPath 4000 V6

Issue 04

• Duplex implementation (see Section 2.3, “Simplex/Duplex”)

• NTP server for time synchronization (see Chapter 6, “Time Synchronization”)


Highlights and Hints

_highlights_hinweise.fm


hipath_4000.fm

HiPath 4000HiPath 4000 in the Customer LAN

2 HiPath 4000

2.1 HiPath 4000 in the Customer LAN

In order to be able to control the IP-based access points/HiPath 4000 SoftGates, the HiPath 4000 control system must be given access to the IP network via which all access points/HiPath 4000 SoftGates can be reached. This is usually the customer’s intranet. Once the “Atlantic LAN“ is an internal HiPath 4000 network and may no longer be linked with the customer network, the control processors of the HiPath 4000 have additional LAN interfaces.

2.1.1 LAN Interfaces for DSCXL2 Processors

Figure 1 LAn interfaces DSCXL2

IMPORTANT: If HiPath 4000 service applications such as the Quality of Service Viewer for IPDA are to be used, the LAN interface of the HiPath 4000 Assistant must be in the HiPath 4000 LAN segment (see “IP Solutions > IP Dirstributed Architecture (IPDA) > HiPath 4000 LAN Segement”)).Routing to the access points/HiPath 4000 SoftGates, which is configured for CC-A or CC-B, must also be configured in the HiPath 4000 Assistant in this case.


HiPath 4000

hipath_4000.fm

HiPath 4000 in the Customer LAN

2.1.2 Checking the IP Addresses Used

If all addresses required by the HiPath 4000 IPDA system have been agreed on with the network administrator of the customer, configuration can commence.

In order to rule out typos and mistakes, all IP addresses should be checked. In other words, check that a new IP address can actually be reached prior to configuration via the ping command. If a response is received, the address already exists in the network.

If you wish to configure a CC-A address first, and the ping responds, you will have to obtain a different address from the network administrator, as an IP address may never be assigned twice. If, on the other hand, you wish to check the IP address of a router and receive no response, it will not be possible to link HiPath 4000 IPDA components via this router without taking additional measures.

The "HiPath 4000 Administration" portal also performs certain consistency checks when configuring the IP addresses.

2.1.3 AP 3700 IP/HiPath 4000 SoftGate with Survivability Unit in the Customer LAN

An AP 3700 IP with a survivability unit requires three connections in the customer’s network:

1. HG 3575 LAN connection of DSCXL2 board

2. DSCXL2 IPDA LAN connection of DSCXL2 board

3. DSCXL2 CUSTOMER LAN connection of DSCXL2 board

A HiPath 4000 SoftGate with survivability unit requires at most two connections in the customer's network:

1. IPDA-LAN connection

2. CUSTOMER-LAN connection

The virtual HG 3575 does not require a LAN connection because the LAN connectivity runs internally between IPDA LAN and vHG 3575. This means connection 1 in the next diagram is obsolete for scenarios with HiPath 4000 SoftGate.


hipath_4000.fm

HiPath 4000HiPath 4000 in the Customer LAN

Figure 2 LAN interfaces of AP 3700 IP

The connections 1 (HG 3575) and 2 (IPDA/DSCXL) must be contained in the same LAN segment, as they must communicate with each other without an intermediary router.

Connection 3 (CUSTOMER-LAN/DSCXL) is required from the HiPath 4000 Assistant of the survivability unit. The following functions are relayed via this interface:

• HiPath 4000 Assistant > Backup and Restore - provision of current backup data from the backup server

• Error and alarm messages to HiPath 4000 Manager/Fault Management and System Management

• Access for applications such as Hardware Data Symptom Diagnosis, etc.

• Remote access for the service

• Collection of charge data collated on the survivability unit (COL)

• Synchronization of the system time with NTP time server or the HiPath 4000 central system

The interfaces 2 and 3 are deliberately listed separately. Many customers want a strict separation of their IP networks for data and voice. Connection 2 must be located in the voice NET for this type of scenario in order to communicate with the HG 3575. This also applies for connection 1. Connection 3 can be located in the data network. Here are no real-time requirements placed on the network. A consolidation could have prevented interface-related prioritization and reduced availability.

In the case of a HiPath 4000 SoftGate, it is also possible to have interfaces 2 and 3 run over a physical address.

IPDA LAN

IPDA LAN

CUSTOMER LAN

Real-Time IP Network

AP

3700

IPPe-

HG

Pe-

Access

CC-

Pe-

HG

HG

Pe-

ADP

CC-

CC-HiP

ath

4000

Central

IPDA LANCUSTOMER LAN

Data IP Network

Backup Server

1

2

3

NTP Time Serv-

HiPath 4000 Manager


HiPath 4000

hipath_4000.fm

Hardware Configurations

The requirements specified in IP Solutions > Gateways HG 3500 and HG 3575 > Network Requirements” and “Network Data” for “IPDA“ LAN ports also apply to interfaces 1 and 2.

The capacity of interface 3 must be configured so that a system version can be completely restored from the backup server.

Assuming that one backup is performed daily and that all survivability units can restore simultaneously and without restrictions, a minimum bit rate of 24 Kbps is required. The maximum possible amount of data (all data is modified and must be transferred) is then transferred in ten hours.

The backup server must have enough memory for a complete backup set. This requires a maximum of approx. 100 MB.

2.2 Hardware Configurations

The following hardware configurations are released with HiPath 4000 V6:

• cPCI

IMPORTANT: The existing DSCXL boards in HiPath 4000 communication server and AP Emergency server including HDMO/HDCF modules will be replaced with the new DSCXL2 server blades.

• 600 ECS (HiPath 4500) with “server conversion”

• Standard Linux Server for standard server deployment

server conversion

This means upgrading to cPCI server.

2.3 Simplex/Duplex

2.3.1 Feature Description

Virtual Machine

With HiPath 4000 V6, both the simplex and the duplex configuration are implemented by means of virtual machines. The underlying operating system is Linux.


hipath_4000.fm

HiPath 4000Simplex/Duplex

On each hardware machine (DSCXL2 board or server PC), separate virtual machines are installed for the CC and the ADP, along with a HiPath 4000 Assistant instance and a HiPath 4000 CSTA instance.

The virtual machines simulate the necessary hardware resources and forward the specific hardware interfaces for the encapsulated realtime software (RMX).

The active ADP is connected to CCA and CCB via the virtual Atlantic LAN. The same Atlantic LAN IP and MAC addresses are used by the virtual machines for the ADP and for the CCs. Moreover, all ADP services that are present in HiPath 4000 V5 are also available in HiPath 4000 V6, e.g. the SWU software can be loaded and accessed externally through the ADP.

Linux High Availability Framework

On each machine in a simplex or duplex configuration, a Linux High Availability Framework is in operation.

It has the following functions:

• Supervise the virtual machine instances for the ADPs, CCs, and HiPath 4000 Assistants/HiPath 4000 CSTAs on the own hardware machine.

• In case of an error, together with the Linux High Availability Framework on the other hardware machine it will be decided whether an ADP switchover is necessary (duplex configuration only).

• Initiate restart or shutdown of the virtual machines for the RMX-based software and HiPath 4000 Assistant/HiPath 4000 CSTA on the own hardware machine, if necessary.

• Prevent inconsistent or insecure states like, for instance, two active ADPs at the same time (duplex configuration only) or hacker attacks.

• Display and log the summarized results of the RMX startup phases for each phase.

• Start and monitor the virtual Atlantic LAN. In case of bad throughput/long delays, it is considered defective.

• Supervise the hard disk replication process (duplex configuration only).

• Display summarized status information about resources on the RMX side, e.g. networks, interfaces, ports, and supply dedicated RMX components with specific RMX-external state information, e.g., virtual Atlantic LAN, ADP status.

• Display failures of the supervised resources in time, e.g. low network quality is too low, slow synchronization, RTM interface unavailability.


HiPath 4000

hipath_4000.fm

Simplex/Duplex

2.3.1.1 Simplex Configuration

In simplex configruation, one DSCXL2 board or server PC is deployed. ADP and SWU run in separated virtual machines.

Figure 3 Simplex mode

2.3.1.2 Duplex Configuration

For duplex configruation, two DSCXL2 boards or server PCs are required.

Based on DSCXL2 board the duplex configuration of HiPath 4000 is realized in one cPCI shelf. The HiPath 4000 basic shelf contains

• two DSCXL2 boards - slot 1 and slot 5 and

• one HDTR - slot 3.

This solution supports redundant LAN ports, the failure of central control (CC), ADP, HiPath 4000 Assistant and HiPath 4000 CSTA. Also, the HiPath 4000 Administration portal will be switched over with ADP, HiPath 4000 Assistant and HiPath 4000 CSTA.

The CCs run in hot standby mode and were supplied with continuous data and status updates over the virtual Atlantic LAN.

The ADP, HiPath 4000 Assistant and HiPath 4000 CSTA run in warm standby mode and need to be restarted in case of failover.

The SWU failover is independent from a failover of the other services.


hipath_4000.fm


Additionally a NTP server is necessary for time synchronization. It is not recommended to use any of the DSCXL2 virtual machines as the NTP server in order not to have a single point of failure (see also Chapter 6, “Time Synchronization”).

Figure 4 Duplex mode (DSCXL2)

Normal Operation

In normal operation ofa duplex confiuration, the virtual machines of the ADP and the HiPath 4000 Assistant/HiPath 4000 CSTA on the primary hardware machine are active, while the correspondant virtual machines on the secondary hardware machine are offline. The ADP and the HiPath 4000 Assistant/HiPath 4000 CSTA, which reside on the same hardware machine, can only change their active/offline states together. Thus, a HiPath 4000 Assistant/HiPath 4000 CSTA can be only active on that hardware machine on which the virtual machine for the ADP is active.

Redundant LAN ports

The LAN ports of the Hipath 4000 Communication Server (with DSCXL2) can be configured in hot redundant mode and connected to two redundant Ethernet switches. L1 failure of one Ethernet switch results in hot switch-over to the redundant Ethernet switch without loosing calls or application connectivity.

The following LAN ports are available:

• 2 LAN ports in hot-redundant mode for call control

• 2 LAN Ports for HiPath 4000 Assistant/HiPath 4000 CSTA

• 2 LAN Ports for HiPath 4000 Duplex


HiPath 4000

hipath_4000.fm

Simplex/Duplex

Replication of ADP, SWU, and HiPath 4000 Assistant/HiPath 4000 CSTA Hard Disk

To enable complete recovery of the RMX-based software and the HiPath 4000 Assistant/HiPath 4000 CSTA in case of failover, the relevant virtual hard disk partitions and files on the primary machine are replicated onto the hard disk of the secondary machine. This is achieved by the DRBD (Distributed Replicated Block Device) software, which replicates the relevant files over the LAN.

If both hardware machines are connected via local network, synchronous replication is used (in DRBD terminology: protocol C). This implies that all data blocks are written on the hard disk of the active machine and, at the same time, on the hard disk of the standby machine. The file system of the active machine is notified when the writing process has been successful on both machines.

Failover Scenarios

see Section 2.3.3, “High Availability Scenarios”.

2.3.1.3 Separated Duplex

IMPORTANT: Decoupled release with HiPath 4000 V6 R1.x.

Due to different locations of the communication server a higher resilience is reached.

Figure 5 Separated Duplex

The following separated deployments are possible:

• HiPath 4000 software installed on two standard server running as separated duplex.

• HiPath 4000 installed on two HiPath 4000 communication server each with one DSCXL2 board.


hipath_4000.fm


• Mixed scenario with standard server and HiPath 4000 communication Server with DSCXL2.

Prerequisistes

• The server needs to be installed in the same L2 broadcast domain.

• The bandwidth must be at least 10Mbit/s.

• The RTT (Round Trip Time) between the 2 servers must be lower than 10 ms.

• Only IP access points (AP 3700IP/AP3300IP) and/or HiPath 4000 SoftGate can be connected.

• Quorum Node software needs to be installed on 3rd independent server (part of HiPath 4000 instalaltionpackage).

Functionality

Figure 6 Functionality of separated duplex

Quorum node prevents the “split brain” situation (delivery with HiPath 4000 installation package).

Failover Scenarios

Like normal Duplex mode (see Section 2.3.3, “High Availability Scenarios”) and additionally total breakdown (e.g. Power Off) or other major hardware / network failures.

2.3.2 Service Information

Separated Duplex

Mixed configuration of a DSCXL2 board and a server PC is possible in duplex mode (separated Duplex (decoupled release with HiPath 4000 V6 R1.x)). However, DSCXL2 specific hardware (e.g. local shelves) is not supported by a mixed configuration.


HiPath 4000

hipath_4000.fm

Simplex/Duplex

2.3.3 High Availability Scenarios

2.3.3.1 Startup DSCXL2

1. The Linux High Availability Framework starts.

2. The CC starts immediately if a connection to the ADP on the other board is established. Otherwise, it will wait until the ADP on the own board is ready.

3. The Linux High Availability Framework tries to contact the Linux High Availability Framework on the other board. If successful, the Linux High Availability Frameworks will decide whether the ADP on this board should be started or not. If the other Linux High Availability Framework is unreachable, the Linux High Availability Framework on this board tries to contact the other ADP. If the other ADP is unreachable, the ADP and the HiPath 4000 Assistant/HiPath 4000 CSTA on this board are started.

4. If the ADP on this board has been started, and the CCs have not been started yet, they can be started now.

2.3.3.2 Failover Scenarios

Error #1: The active CC breaks down or is restarted

Figure 7 Failure in active CC

Due to a break down or restart of the active CCA it is no longer available.

CCB, which has been on standby previously, will assume the active role. CCA gets switched to standby.

In case of SWU failover:


hipath_4000.fm


• no loss of established calls.

• no data loss (e.g. billing, configuration data, etc.).

• other virtual machines (ADP, HiPath 4000 Assistant, HiPath 4000 CSTA, HiPath 4000 Administration Portal) are not affected.

Error #2: The active ADP breaks down / gets unreachable

If the Linux High Availability Frameworks on both boards are available and decide that a failover is necessary, the previously active ADP, HiPath 4000 Assistant and HiPath 4000 CSTA on board A will be turned offline, and the ADP, HiPath 4000 Assistant and HiPath 4000 CSTA on board B will be started up.

Due to hard disk mirroring between both machines (see Replication of ADP, SWU, and HiPath 4000 Assistant/HiPath 4000 CSTA Hard Disk), the ADP virtual machine and HiPath 4000 Assistant/HiPath 4000 CSTA can start up with the latest software and data. To the external applications, an ADP failover appears as a connection loss and a loss of dynamic data. Thus, the external applications need to reconnect to the ADP.

In case of ADP failover:

• No loss of established calls.

• Restart of the virtual machines of ADP/ HiPath 4000 Assistant (offline time < 5 - 10 minutes).

• Restart of the virtual machine of HiPath 4000 CSTA (offline time < 5 minutes).

• No new connections/calls can be established during the switchover.

• Loss of dynamic data in RAM and active connections during the switchover.

• To the external applications, an ADP failover appears as a connection loss and a loss of dynamic data. Thus, the external applications need to reconnect to the ADP.

HiPath 4000 Assistant / HiPath 4000 CSTA failover

The HiPath 4000 Assistant / HiPath 4000 CSTA play a passive role in the ADP failover. The Linux High Availability Framework does not consider its state in the failover decision. However, the HiPath 4000 Assistant / HiPath 4000 CSTA on the secondary hardware machine can only be started if the previously active one has been turned down completely. For this purpose, the Linux High Availability Framework will send a shutdown request to the HiPath 4000 Assistant / HiPath 4000 CSTA. Hereupon, the HiPath 4000 Assistant / HiPath 4000 CSTA will shut down all of its components internally.


HiPath 4000

hipath_4000.fm

Simplex/Duplex

Error #3: Active DSCXL2 Board becomes unreachable

Figure 8 DSCXL2 board is unavailable

Due to a hardware or software failure or due to maintenance the aktive DSCXL2 board becomes ureachable.

CCB, which has been on hot standby, assumes the active role now.

The Linux High Availability Framework of board B realizes the unavailability of the partner Linux High Availability Framework residing on board A and decides for the activation of the ADP and HiPath 4000 Assistant on board B.

When board A recovers, CCA will be started and acts as stndby CC. The Linux High Availability Framework on board A realizes that the ADP on board A should not be started because the ADP on board B is active already.

2.3.4 Generation (Example)

Manual switch over of CC

With AMO REST you can invoke a manual switch over of the CCs.

EXEC-REST:TYPE=UNIT,UNIT=BPA,RSLEVEL=RESTART;

or

EXEC-REST:TYPE=UNIT,UNIT=BPB,RSLEVEL=RESTART;

Manual switch over of ADP

The active ADP can be shut down, e.g. for maintenance.

HiPath 4000 Administration > Maintenance > Shutdown System


hipath_4000.fm

HiPath 4000Supported Interfaces

Figure 9 System shut down with HiPath 4000 Administration

2.4 Supported Interfaces

HiPath 4000 supports the following interfaces:

Trunks

• S0 (basic rate interface)

• E1 (S2M) (primary rate interface 30 channels)

• T1 (primary rate interface 24 channels)

• Analog

• Native SIP (SIP service provider)

Networking interfaces

• Basic Rate S0 / Primary Rate E1 (S2M) / T1

The following protocols are supported:CorNet NQ, QSIG, DSS1, CAS

• Analog e.g. MFC-R2, E&M, ...

• IP trunking (H.323 Annex M1)

• SIP trunking to HiPath platforms with SIP-Q protocol

• Native SIP trunking for IP interoperability with 3rd-party manufacturers

User interfaces

• UP0/E

Twin-wire interface for connecting OpenStage T telephones

• HiPath Feature Access (HFA) for OpenStage HFA endpoints

• Native SIP for IP Endpoints:

e.g. OpenStage SIP

• S0 bus


HiPath 4000

hipath_4000.fm

Corresponding Products

S0 port for ISDN terminal devices

• a/b port (CLIP, name display, and MWI possible) for analog terminal devices

2.5 Corresponding Products

Application / Product required version

Devices, Adaptors and Gateways

OpenStage HFA V2

OpenStage SIP V2

OpenStage T V2

optiPoint 500

optiPoint 4x0 Cornet IP

AP 1120 Cornet IP

Mediatrix 41xx

Mediatrix 44xx

Mediatrix 1204

Mediatrix 36xx

OpenScape Personal Edition HFA V3

OpenScape Personal Edition SIP

LifeSize Room / Team / Express

IP Networking

OpenScape Voice V4 R1 / V5 R0 SIP Q V2

HiPath 3000 V8 SIP Q V2

HiPath 4000 V2.0 CorNet IP

HiPath 4000 V3.0 SIP Q V1

HiPath 4000 V4 and V5 SIP Q V2

TDM Networking

HiPath 4000 V2.0 / V3.0 / V4 / V5

HiPath 3000 V8

Applications

HiPath 4000 Manager V6

OpenScape UC Application V4 R0

HiPath Fault Management V4

HiPath User Management V2

HiPath QoS Management V1

OpenScape ComAssistant V2.0

Table 1 Corresponding products


hipath_4000.fm

HiPath 4000Licensing

2.6 Licensing

As of HiPath 4000 the license concept based on the HiPath License Management (HLM). The SIM card is no longer needed. Please send the SIM card together with the delivery note to the following address:

Siemens-Enterprise Communications GmbH&Co.KGSEN VA LP PSM 4Kc/o Mr. Battke / Mr. VogtHofmannstrasse 5181379 MunichGermany

Licensing will not change for the older HiPath 4000 systems (V5 and before).

There is a HiPath 4000 V6 flex license for each port for all HiPath 4000 stations and trunking connections: analog, digital, HFA, SIP, cordless, PSTN and SIP service provider.

For which license is to be used please refer to the sales information of HiPath 4000 V6.

OpenScape Xpressions V5 / V6 native SIP for conferencing,Cornet IP for messaging,ACL-C/CSTA.ASN1 for call control

OpenScape Contact Center V8

HiPath Trading V3

OpenScape Xpert V4

HiPath CAP V3.0

HiPath DTB V9.0

Attendant Suite

AC Win IP V2

BLF-Win V3

DS-Win V4

OpenScape Alarm Response Professional V3

Mobility

HiPath Cordless E V3.0

HiPath Cordless IP V1

OpenScape MobileConnect V3

optiPoint WL2 professional

Application / Product required version

Table 1 Corresponding products


HiPath 4000

hipath_4000.fm

Portlist

A grace period license is created automatically with the first portal configuration, which remains valid for 30 days.

A customer license must be created by specifying the MAC address (e.g. eth0 of DSCXL2 board) and the system number in the Central License Server (CLS). The number of licenses required is specified here. The generated ".lic" file can be loaded into the HiPath 4000 Assistant using the "License Management" application. The HiPath 4000 Assistant generates a codew from this for the RMX.

Licenses can be loaded and displayed in the HiPath 4000 Assistant in the Access Management > License Management menu. Click Browse to search for and select the license file on your PC or drives. Then confirm your selection with Send. The license file is thereby copied to the predefined directory.

Information on the number of purchased, used, free and blocked licenses is available as before in AMO CODEW.

For more information on the License Management Tool (LMT) please refer to the administrator documentation (http://apps.g-dms.com:8081/techdoc/de/P31003H3460M1190176A9/index.htm).

For more information on the HiPath License Management please refer to the intranet: https://enterprise-businessarea.siemens-enterprise.com/hlm/default.aspx.

For more information on the central licence server please refer to the Intranet: https://www.central-license-server.com/license-management/session/login.htm.

2.7 Portlist

The Interface Management Database (IFMDB) contains information regarding the IP ports used by all HiPath 4000 products.

https://apps.g-dms.com/ifm/

2.8 Applications, Loading Tables and Selections

This chapter describes ADP/ADS and SWU applications (APL), loading tables (CLT) and selections (SEL).

These tables are used for loading the APS subsystems into the specific individual memory areas on HiPath 4000 V5 or on the hard disk.

All three table types are administered in CmCntrl (CLT type with APL element for applications and SEL for selections) and delivered as subsystems to the APSs.


hipath_4000.fm

HiPath 4000Applications, Loading Tables and Selections

2.8.1 ADP/ADS

2.8.1.1 Applications

ADP/ADS applications are delivered to the ZAPLTABD subsystem in the ADP/ADS APS.

ADP/ADS applications are function-specific. An ADP/ADS application contains one or more subsystems which are necessary for executing a specific function. ADP/ADS applicaitons are activated from the first installer / HiPath 4000 Administration > LAN WIzard dependent on the selected deployment.

2.8.1.2 Loading Tables

ADP/ADS contains "blank" and "filled" loading tables.

"Blank" loading tables

Subsystems are entered in "blank" loading tables when applications are activated.

• ZADSCAT0

• ZADSCMT0

"Filled" loading tables

"Filled" loading tables ensure that the ADP/ADS of a system is initially downloaded in accordance with a specific system configuration.

2.8.1.3 Selections

ADP/ADS selections are delivered in the subsystem ZSELEDC0 in the ADP/ADS APS.

ADP/ADS selections are function-specific. They contain subsystems for a specific scope of functions. An ADP/ADS selection is activated rom the first installer / HiPath 4000 Administration > LAN WIzard dependent on the selected deployment to load the specific subsystems onto the hard disk.

Subsystems not listed in a selection are always loaded onto the hard disk (HD).

2.8.2 SWU

In the following sections you will find information about the Applications and Loading Tables of the SWU.


HiPath 4000

hipath_4000.fm

Hardware Architecture Table

There are no selections in the SWU. All SWU-APS subsystems are always loaded onto the disk for each configuration level.

2.8.2.1 Applications

SWU applications are delivered in the ZAPLTABS subsystem in SWU APS.

SWU applications are configuration-specific. There is a basic application which is delivered in every SWU configuration level.

The appropriate applications for the call charge pool (internal and external) are loaded for all configurations.

2.8.2.2 Loading Tables

There are three blank loading tables for SWU:

• ZSWUBPT0

• ZSWUCAT0

• ZSWUCMT0

The loading tables are completed by the AMO APC during loading on the basis of the information in the hardware architecture table (see Section 2.9, “Hardware Architecture Table”). The memories are then loaded from this table.

2.9 Hardware Architecture Table

The hardware architecture table is an ASCII file on the :PDS: area of the hard disk. It can be displayed with:

e.g. STA-LIST:":PDS:APSU/HWARCH0",,,M,N;

The hardware architecture table shows among other things which parameters have been configured during deployment installation for the AMOs DBC and APC for a given ARCHITECTURE and a given ARCHITECTURE TYPE.

2.10 Hard Disk

The hard disk is part of the DSCXL2 board.


hipath_4000.fm

HiPath 4000Hard Disk

2.10.1 Layout

Areas on the hard disk (RMX)

2.10.2 Configuration Batch

Set up the hard disk on controller 1

ADD-DTSM:A1,HD,45775,512,"STDH6",255;

ADD-DCSM:A1,1,HD,"STDH6";

ADD-DASM:A1,1,7200&1600&2400&1120&16384&7200&9868,4096&4096&4096&4096&4096&4096&4096;

ADD-DLSM:A1,1,E,":PDS:";

ADD-DLSM:A1,1,F,":DBDA:"&":DBD:"&":TMD:"&":PAS:"&":AMD:"&":DMP:";

ADD-DLSM:A1,1,G,":CGD:";

ADD-DLSM:A1,1,H,":DMS:"&":DSY:";

ADD-DLSM:A1,1,I,":SCR:";

ADD-DLSM:A1,1,J,":GLA:";

ADD-DLSM:A1,1,K,":DIAG:";

Set up of a virtual hard disk on controller 4 (for system backup)


ADD-DASM:A1,4,7200&1600&2400&1120&16384&7200&9868,4096&4096&4096&4096&4096&4096&4096;





AREA Logical name Size in 64k blocks Size in MB

A Administration area 2 0

E PDS 7200 450

F DBDA 1600 100

G CGD 2400 150

H DMS (DSY) 1120 70

I SCR 16384 1024

J GLA 7200 450

K DIAG 9868 617

Table 2 Hard disk layout


HiPath 4000

hipath_4000.fm

Smart Services Delivery Platform (SSDP)

ADD-DLSM:A1,4,I,":MOD-SCR:";



Set up of a virtual hard disk on controller 6


ADD-DASM:A1,6,7200&1600&2400&1120&16384&7200&9868,4096&4096&4096&4096&4096&4096&4096;





ADD-DLSM:A1,6,I,":MOD-SCR:";



2.11 Smart Services Delivery Platform (SSDP)

SSDP - Smart Services Delivery Platform is an additionl Remote Service Platform to SIRA and connects our customer systems and products via fast and secured Internet connection to our Siemens Enterprise Communications remote service infrastructure.

SSDP supports all the usual Web Services Standards, including the Hypertext Transfer Protocol (HTTP), Simple Object Access Protocol (SOAP) and Extensible Markup Language (XML).

All components of the Smart Services Delivery Platform have been certified by the SSL (Secure Sockets Layer) certification authority VeriSign. Communications between the customer side and the Remote Service Center are always secured using 128-bit SSL encryption.

Figure 10 Smart Services Delivery Platform - SSDP

For more information please refer to the SEN intranet:


hipath_4000.fm

HiPath 4000Smart Services Delivery Platform (SSDP)

• Configuration Guide:

https://www.g-dms.com/livelink/livelink.exe/Open/38045591

• Configuration Checklist:

https://www.g-dms.com/livelink/livelink.exe/Open/38760746


HiPath 4000

hipath_4000.fm

Smart Services Delivery Platform (SSDP)


hipath_4000_assistant.fm

HiPath 4000 AssistantHiPath 4000 Assistant Applications

3 HiPath 4000 Assistant

3.1 HiPath 4000 Assistant Applications

This chapter describes the applications installed during the installation process. It also gives a short overview of the tasks performed by each application.

For further information about the applications, please refer to the corresponding online help.

Software Management

• Application Administration

The "Application Administration" application is needed to install, replace, and remove applications. In addition, you can display the names of the installed applications and the installation packages that are on the installation medium. DVDs, CDs, USB Memory Devices, and the installation directory on the hard disk can be used as installation media.

• Backup & Restore

The “Backup & Restore” allows you to save configuration data or software from RMX and Linux applications to a backup copy file and restore the data as required. This means that an accurate backup copy of the data and/or software is available in the event of a system failure.

• Software Activation

When either a Revision Level Complete RLC (Minor Releases / Fix Releases) or a Patch Package PP (Fix Releases / RMX-HotFixes) is transferred using Software Transfer to a HiPath 4000 system running SUSE Linux Enterprise Server (SLES), it must be subsequently activated there. The Software Activation service function is used for activation.

• Software Transfer

The SWT2 (Software Transfer 2) component is part of HiPath 4000 Assistant. It is a tool for transferring the following Hotfixes and Releases via a TCP/IP network:

– Hot Fixes HF / CSTA HotFixes (CSTA_HF),

– Hot Fixes HF / HiPath 4000 Platform Hot Fixes (PLT_HF),

– Hot Fixes HF / RMX Hotfixes (RHF),

– Hot Fixes HF / Unix Hot Fixes (UHF),

– Fix Releases FR (Patch Packages (PP) / Revision Level Complete (RLC)


HiPath 4000 Assistant


HiPath 4000 Assistant Applications

– Minor Releases MR (Patch Packages (PP) / Revision Level Complete (RLC)

• TSDM

TSDM is an abbreviation for TDM Software Download Manager. This application enables software updates on TDM (Time Division Multiplex) variants of OpenStage phones and the Up0 Extender on HiPath 4000 systems. In addition, a customer logo can be delivered to OpenStage devices supporting this feature, trace and exception log data can be uploaded from the OpenStage device to the switch.

Access Management

Access Management is the access control component for HiPath 4000 servers. It controls which users are allowed to access a specific server, and which applications and access rights these users may use. Possible users are customer administrators and service technicians that manage HiPath 4000 systems.

• Session Management

– Change Password

– Emergency Password Reset Configuration

Emergency Password Reset (EPR) provides a mean to reset administrator (user "engr") password in case the password was lost or the system was corrupted. Prior to using that feature, the system must be configured appropriately, and the feature must be enabled by the system administrator.

– Password Histroy Configuration

– Session Manager

• License Management Tool

• License Management

The License Management application allows the administrator to obtain information on the installed licenses and to configure the location of the CLA. This protects all HiPath 4000 applications and all software that requires a license and that a customer might want to install.

• Account Management

– User Account Administration

– System Account Administration

– Access Right Configuration

– Access Right Group Configuration




– Export User Reports

• Manage Web Server Certificates

– Certificate for this Web Server

– Activate

– Generate

– Import

– Generate via CSR

– Certificate Network Management

– Root Certificate

– Sign CSR signieren

Base Administration

• Webmin

“Webmin” is the basic administration service for the configuration of the system resources and the TCP network. It is also used for operating the system, e.g. shutdown.

• Logging Management

Logging Management allows you to search the logon events, using a standard query. It also allows you to modify, create and save queries.

• Application Control

Expert Mode

• HiPath 4000 Expert Access

For additional information, refer to the online help.

• HG 35xx Web Based Management

• Connect to HiPath 4000 Portal

• SSH connection to Assistant

• LW Update Manager

• Connection to HiPath 4000 CSTA

• Signalling and Payload Encryption Administration




HiPath 4000 Assistant Applications

With the “Signalling and Payload Encryption Administration” dialog of the HiPath 4000 Assistant it is possible to set APN SecureTrace PassPhrase (Access Point Network) and MEK (Master Encryption Key).

• Direct WBM/SSH Access

"Direct WBM/SSH Access" is an application that enables automatic/manual password distribution for all accounts on IP boards, and for creating, editing (i.e. updating) and deleting additional user accounts as well.

The application is accessible for administrators only and ensures secure password distribution.

System Management

• HiPath 4000 Administration

• PhoneMail Administration

• HiPath 4000 / HG3500 Administration

Configuration Management

Configuration Management (CM) enables the system- and/or network-wide configuration of system data, line (trunk) data, station data, least cost routing, and personal data.

Das Configuration Management includes the following functions:

• Network

• System Data

• Station

• Tables

• Groups

• Personal Data

• Least Cost Routing

• HiPath Inventory Management

• IPDA Wizard

• Scheduled Batch

• Session Log

• CHESE Wizard




• User Settings

Collecting Agent

The Collecting Agent is used to collect accounting data in an HiPath 4000 network. Collecting Agent is a basic function of Accounting Management (AM).

Performance Management

• Performance Management

Performance Management (PM) is a measurement tool for HiPath 4000 systems. PM allows you to generate various reports on metered data stored in the PM database.

The data for PM comes from the CDR records, ZAUSL files and CMI files collected by Collecting Agent (COL).

Diagnostics

• Fault Management

– HiPath 4000 Alarm Configurator

The Alarm Configurator is used to manage switch alarms. It is used to assign alarms to subscribers or trunks and to generate alarms automatically for trunks to which alarms have not yet been assigned.

– SNMP Configurator

SNMP is used to provide a standard interface for monitoring and configuring network resources.

SNMP is based on the manager / agent model. Agents maintain management information databases, which can be read and possibly written by managers. This kind of communication is always initiated by the managers. Agents are also capable of sending notification events, so-called "traps", to the managers asynchronously. Apart from these operations, the SNMP protocol definition also includes the data model and the network protocol.

• Switch Diagnosis Support

– Real Time Diagnosis System




User Accounts

Realtime Diagnosis System (RDS) provides telephony fault localization for station and data lines and limited trunk fault reporting capabilities for trunk facility problems. It provides tools and features to help reduce the time of solving trunk problems, as well as enabling you to solve the problems more efficiently.

• Trace Download

• Test Simulation of Key Function Activity (TSKA)

The TSKA application enables the HiPath 4000 Assistant user to display and simulate OptiSet, optiPoint and OpenStage devices at a customer's site. TSKA displays:

– display messages,

– LED status,

– function key assignments,

– "Self Labeling Key" texts.

The user can remotely simulate the pressing of function keys and keys of the keypad. Therefore, a graphical representation of the device in a browser window is provided.

TSKA allows also to open the WBM (Web Based Management) page for an IP Phone connected via a CGW board.

Report Generator

Report Generator is used to work with report templates and to run reports.

3.2 User Accounts

3.2.1 Definition

Ten different user accounts are supported by Security Manager: five for HiPath 4000 Assistant/Manager and five for HiPath 4000 HTS. Only the accounts relevant to HiPath 4000 Assistant are described in this chapter.

The five user accounts are shared as follows:

• Three for customer service levels (engr, rsta, rsca)

• Two for the customers (cusa, cust)

Every user who logs on to a HiPath 4000 server is assigned one of these levels.



HiPath 4000 AssistantUser Accounts

For safety reasons, you are asked to change the pre-defined password the first time you log on.

The following table provides an overview of the different user accounts.

Refer to the Security Management (SecM) online help for further information (for example passport rules).

3.2.2 Customer Account Profiles for HiPath 4000 Assistant

User account

Password issued by

Additional information

rsca Siemens2000 Remote Service Customer Assistance (limited system administration privileges).For "lower level" service technicians.

rsta Siemens2000 Remote Service Technical Assistance (limited system administration privileges).For "upper level" service technicians.Access for rsca security level.

engr Siemens2000 Engineer (comprehensive system administration privileges for engineers).Access for all security levels

cusa c.u.s.a Customer Security Administrator (limited system administration privileges for "customer security administrators").For "master" administrators employed by the customer.Access for security level cust.

cust -- Customer (standard user).Individual accounts for the relevant customer environment can be set up during the runtime.

Navigating the start page Cust.account

Application Definition Service Cust.

ACDAPP Call Center Configuration Administrator rsca cusa

ACDAPP Call Center Configuration Client User rsca cust

ACDAPP Call Center Administration rsca ---

ACDAPP ACDAPP Status rsca cust

APP Application Installer engr ---

CM Configuration Management rsca cust

COL COL Basic Features rsca cust

Direct Access

Expert Access rsta ---

Table 3 HiPath 4000 Assistant - Customer Account Profiles




User Accounts

Direct Access

HiPath 4000 Assistant Launchpad rsca cust

Direct Access

Phonemail Logon rsca cust

FTW FTW feature text rsca cust

FM Fault Management ACL-C Tracer rsca cust

FM Fault Management - Batch Generator rsca cust

HBR Administration Backup Device rsca ---

HBR Backup rsca ---

HBR HBR_Common rsca cust

HBR GLA/PDS Handling rsca ---

HBR Restore rsca ---

HBR Backup Schedule Configuration rsca ---

HG3550M HG35xx Web Based Management rsca cust

HG3550M Loadware Manager rsca cust

HG3550M SecureTrace passphrase update engr cust

HG3550M MEK Distribution rsca cust

HSD Hardware and Symptom Diagnosis rsca ---

LAP2 All LAP2 functions rsca cust

LicM License Management rsca cust

LMT License Management Tool rsca cust

LogM Logging Management rsca cust

PM Performance Management rsca cust

RCon Remote connection to Portal and CSTA rsca cust

RDS Real Time Diagnosis System rsca ---

RepGen Report Generator rsca cust

SecM Emergency Shell Access rsca ---

SecM Direct AMO dialog rsta ---

SecM RMX file system rsta ---

SecM Security Profile Definition rsca ---

SecM Unix file system rsca ---

SecM Access right configuration for customer level users rsta cusa

SecM Access right group configuration for customer level users

rsta cusa

SecM Change Password rsca cust

SecM Administration of customer level users rsta cusa






HiPath 4000 AssistantNotification Mechanism and Usage Scenarios

3.3 Notification Mechanism and Usage Scenarios

This section is intended to provide clarification of functionality and interaction when AMOs and HiPath 4000 Manager and/or HiPath 4000 Assistant are used at the same time for switch configuration.

Information is provided in the form of answers to frequently asked questions (FAQ).

Section 3.3.2, “Networks without HiPath 4000 Manager” addresses networks involving AMOs and HiPath 4000 Assistant, but without HiPath 4000 Manager.

Section 3.3.3, “Networks with HiPath 4000 Manager” addresses networks involving AMOs, HiPath 4000 Assistant and HiPath 4000 Manager.

SecM Administration of predefined system accounts rsca cusa

SecM Manage customer administrator level sessions rsta ---

SecM Manage customer level sessions rsta cusa

SecM Manage expert level sessions engr ---

SecM Manage own sessions rsca cust

SecM Manage first level service sessions rsta ---

SecM Manage second level service sessions engr ---

SysM System Management full access rsca cust

SWA/SWA2 All Software Activation functions rsta ---

SWT2 All SWT2 functions rsta cust

TSDM TSDM application rsca cust

TSKA Test Simulation of Key Function Activity rsca cust

UBA CMX Configuration rsca cust

UBA LAN Configuration rsca cust

UBA System Administration rsca cust

XIEAPI Extended Import Export Interface rsca cust







Notification Mechanism and Usage Scenarios

3.3.1 The Notification Mechanism

How the Assistant database is synchronized with the switch database

This section of the document explains the notification mechanism. This mechanism keeps the Assistant database synchronized with the switch database when AMO commands are executed (with anything other than the Assistant itself: direct AMO commands, AMO commands coming from the HiPath 4000 Manager, etc.).

3.3.1.1 Operation of the Notification Mechanism

This is how the notification mechanism works (numbered steps refer to Figure 11 Notification Mechanism):

1. An AMO command is executed on the switch.

2. The switch updates its database.

3. The switch sends a notification to the Assistant, with the AMO command that was executed.

4. The Assistant puts the notification in its internal queue.

5. As soon as it can, it retrieves the notification from that queue.

6. The Assistant generates one or more query AMO commands to retrieve the changes from the switch database (query AMO commands are commands like REG-<NOUN>, DISPLAY-< NOUN>, EXEC-UPLOL, EXEC-UPLO2, that is, AMO commands that read the switch configuration).

7. The Assistant updates its database using the information just queried from the switch.

Figure 11 Notification Mechanism




3.3.1.2 AMO Commands Generated for Notifications

The Assistant generates as few AMO commands as possible, only enough to retrieve the changes from the switches, but it also takes care of all ramifications of an AMO command. For example, if the user adds a new station (ADD-SBCSU), the Assistant executes the following query AMO commands to update its database (the newly created station is the first line, then comes the DIMEN counters, dial plans, PINs, etc., all related to that station):

EXEC-UPLO2:TYPE=PORT,STNO=<NUMBER>,DMSVER=V600;

EXEC-UPLO2:TYPE=COSX,DMSVER=V600;

EXEC-UPLO2:TYPE=DIMEN,DMSVER=V600;

EXEC-UPLO2:DIMEN,V600;

EXEC-UPLO2:DPLNET, <NUMBER>,,,,V600;

EXEC-UPLO2:DPLN2, <NUMBER>,,,,V600;

EXEC-UPLO2:DPLN1, <NUMBER>,,,V600;

EXEC-UPLO2:PIN, <NUMBER>,,,V600;

EXEC-UPLO2:DYNKEY, <NUMBER>,,V600;

3.3.1.3 Possible Sources of AMO Notifications

Any action that changes the switch database will generate notifications to the Assistant. The most obvious source of database changes is direct AMO commands. A second source of AMO commands is the HiPath 4000 Manager. All configuration changes executed on the Manager are translated into AMO commands sent to the affected switches. These AMO commands result in notifications for the Assistant. A third source of AMO commands are changes made from telephones, for example, fixed call forwarding, name key programming, etc. These changes have to be stored in the switch database. Therefore, the switch also sends notifications when they happen.

3.3.2 Networks without HiPath 4000 Manager

IMPORTANT: Basic Usage RuleIf the customer does not have HiPath 4000 Manager, use the Assistant to make configuration changes, not direct AMO commands.

You can find the following Frequqently Asked Questions (FAQ) in this section:

• What happens if I use AMO commands to change the switch configuration, bypassing the HiPath 4000 Assistant?





• How long does it take to update the Assistant database when an AMO command is executed?

• What will the user see on the Assistant until the (Informix) database is updated?

• Does the Assistant notify the users after updating its database?

• Does the notification process affect the Assistant performance?

• Does the notification process slow down the execution of direct AMO commands?

• What happens if I execute a lot of AMO commands in a short period of time, e.g., run an AMO batch file?

• I have to execute a large AMO batch file to update a customer configuration. How should I proceed?

• Is there any automatic mechanism to synchronize the Assistant database when it goes out of sync?

What happens if I use AMO commands to change the switch configuration, bypassing the HiPath 4000 Assistant?

The switch notifies the Assistant that an AMO command (exactly which AMO command) was executed. The Assistant retrieves the affected parts from the switch database and updates its database. To retrieve the affected parts, the Assistant executes AMO commands (EXEC-UPLO2, REG-<AMO>, etc., depending on which AMO was executed). This notification process keeps the switch and the Assistant databases in sync with each other. Refer to Section 3.3.1, “The Notification Mechanism” for a technical explanation of the notification mechanism.

How long does it take to update the Assistant database when an AMO command is executed?

Anywhere from 30 seconds to 3 minutes. The time to update the database depends on:

1. what was changed on the switch (for example, deleting a station takes longer to finish than adding a firewall entry with AMO BDAT, because of all the possible side-effects of the station in the groups, routing, dial plan, etc.);

2. what the Assistant is doing at the time. If it is processing a request from its users, it will first finish that request, and then it will process the notification;

3. the switch configuration (processor speed, number of processors, amount of RAM, etc.).

What will the user see on the Assistant until the (Informix) database is updated?

The old data (before the AMO command was executed).




Does the Assistant notify the users after updating its database?

No. If, for example, the user is looking at the configuration of station 2300 using the Assistant, and in the meantime someone changes the configuration of that station using AMO commands, the Assistant will update its database, but it will not tell the user that the database has been updated. The user is now looking at old data. If the user decides to make changes to this old data and save the changes, it will overwrite what has just changed on the switch. Note that this is no different from having two Assistant users trying to work on the same station at the same time. This should never happen. An object should be modified from one place at a time only.

Does the notification process affect the Assistant performance?

Yes. The Assistant is able to process one request at a time. While the Assistant is processing an AMO notification, it will not be able to process requests coming from its own user interface. In other words, a request coming from the Assistant user will have to wait until the notification is processed. For the Assistant user, it looks like the Assistant is running slowly, when in fact the Assistant is busy doing something else (the notification processing).

Does the notification process slow down the execution of direct AMO commands?

Yes. The switch can execute only one AMO command at a time. If the Assistant is executing AMO commands to synchronize its database, AMO commands coming from other sources will have to wait their turn.

What happens if I execute a lot of AMO commands in a short period of time, e.g., run an AMO batch file?

There is a limited notification queue between the Assistant and the switch (it can hold up to 25 AMO commands in its default configuration). If that notification queue overflows because the Assistant cannot keep up with the AMO commands, the Assistant will send a command to the switch to stop the AMO notifications and will put its database in out-of-sync state. Notifications will remain disabled until the next upload is executed from the Assistant (either a manual upload or the nightly upload).

I have to execute a large AMO batch file to update a customer configuration. How should I proceed?

Do not use the Assistant while the AMO batch file is running. If the AMO batch is large enough, it will eventually overflow the notification queue (see What happens if I execute a lot of AMO commands in a short period of time, e.g., run an AMO batch file?). This will stop the notification mechanism and put the Assistant database in out-of-sync state. If you have to use the Assistant immediately after executing the AMO batch file, run an upload. Otherwise, just wait for the nightly upload to do its job. In the next morning the Assistant database should be synchronized with the switch database.





Is there any automatic mechanism to synchronize the Assistant database when it goes out of sync?

Yes. Every night (at midnight, in the default configuration) the Assistant synchronizes its database with the switch database. On a quiet system (with no activity between midnight and the next morning), the Assistant database should always be in sync with the switch database in the morning.

3.3.3 Networks with HiPath 4000 Manager

IMPORTANT: For informationen on networks with HiPath 4000 Manager please refer to “HiPath 4000 Manager, Installation- and Service Manual” (http://apps.g-dms.com:8081/techdoc/en/P31003H3460S101017620/index.htm).


hipath_4000_csta.fm

HiPath 4000 CSTA

4 HiPath 4000 CSTA


HiPath 4000 CSTA

hipath_4000_csta.fm


installation_configuration.fm

Installation and ConfigurationGeneral Notes

5 Installation and Configuration

5.1 General Notes

IMPORTANT: HiPath 4000 runs exclusively on the Linux machine (no other application is allowed to run co-located on the machine, e.g. virus scan).

• The HiPath 4000 software is able to run on DSCXL2 boards or, alternatively, on regular server PC hardware.

IMPORTANT: However, local shelves/LTUs are not supported in a server PC environment; these require the Rear Transition Module (RTM), which is only available on DSCXL2 boards.

• The HiPath 4000 Assistant components must run on the same hardware on which the RMX-based Switching Unit (SWU) and the Administration and Data Processor (ADP) are running.

5.2 Available Deployments

As of HiPath 4000 V6 R1 the following deployments are available:

• AP-E

• RG 8300

• Simplex

• Duplex

• Separated Duplex

• Duplex Replacement

For more information on the deployments please refer to the documentation of the HiPath 4000 Administration Portal.

5.3 Suse Linux Enterprise Server Operating System Software Handling

• HiPath 4000 SoftGate


Installation and Configuration

installation_configuration.fm

First Installation

Server application model

IMPORTANT: Please pay attention to the security policy “Support of Operating System Updates for Server Applications”:https://www.g-dms.com/livelink/livelink.exe/open/25860792 orhttp://wiki.siemens-enterprise.com/images/c/c0/Security_Policy_-_Support_of_Operating_System_Updates_for_Server_Applications.pdf).

• All other deployments

Appliance model

Software corrections for the SLES 11 operating system, which are necessary for a failure-free operation, will be provided through SEN.

5.4 First Installation

Please refer to the release note of HiPath 4000 V6 R1.


time_synchronization.fm

Time SynchronizationConfiguring the Time on the HiPath 4000 Platform

6 Time SynchronizationThe HiPath 4000 platform is the time source for all servers in the network (e.g. HiPath 4000 Assistant, HiPath 4000 CSTA, ADP, CCs, Access Points, HiPath 4000 SoftGates, CC-APs, HiPath Access modules, Survivable HiPath 4000 SoftGates).

Figure 12 Time synchronization - overview

6.1 Configuring the Time on the HiPath 4000 Platform

Before the virtual machines are started with the applications (e.g.: HiPath 4000 Assistant, HiPath 4000 CSTA, ADP, CCs, HiPath 4000 SoftGates), the current date and time must be set on the HiPath 4000 platform.

The HiPath 4000 platform is configured so that it gets its time from a Network Time Protocol (NTP) server located in the IP network.

This NTP server is used for time synchronization in the HiPath 4000 network. All virtual machines, terminals and servers synchronize themselves with this NTP server.

IMPORTANT: HiPath 4000 V6 nodes must not be used as NTP servers to avoid single point of failure.HiPath 4000 systems with an older version must also not be used as the NTP server due to performance issues with UnixWare 7.

The date/time module from YaST can be used for this purpose.


Time Synchronization


Configuring the Time on the HiPath 4000 Platform

YAST --> Clock and Time Zone

Figure 13 Date and time module of YaST

The setting of a time zone is optional because it does not impact the time zones on the HiPath 4000 Assistant or ADP (see also Section 6.3, “Configuring the Time Zones”).

1. Click Change.

2. Select Synchronize with NTP Server.

Synchronize with NTP Server: Enter the NTP server address.

Confirm your input by selecting Configure.

Figure 14 Datums- und Zeiteinstellung mit YaST

Important information for setting or changing the time

• If the time is turned back manually on the NTP server by a large time frame, make sure that all virtual machines are shut down. If the virtual machines are not shut down, you have to perform a restart (e.g. via the HA Resource Manager). Otherwise, problems may arise with the virtual real-time clock.



Time SynchronizationConfiguring the Time on all Servers

If the time on the NTP server is only reset by a small time frame by the ntpd, synchronization is performed automatically. The virtual machines do not have to be shut down and a restart also does not have to be performed.

• If the time is predefined on the NTP server (regardless of whether manually or via ntpd, regardless of what scale), synchronization of all virtual machines is performed without any problems.

6.2 Configuring the Time on all Servers

The system time of the HiPath 4000 platform is transferred to all servers when all virtual machines are started.

Synchronization of the HiPath 4000 Assistant is performed via ntpd within approx. three minutes. Synchronization of the ADP is performed within approx. two minutes.

Check in the HiPath 4000 Assistant whether the date and time have been synchronized correctly:

Base Administration > Webmin > System Administration "Date/Time”

IMPORTANT: The date and time cannot be configured in the HiPath 4000 Assistant!

6.3 Configuring the Time Zones

The time zone is independent for every server on the HiPath 4000 V6. If the time zone is to be changed, it has to be set separately for the HiPath 4000 platform, HiPath 4000 Assistant and HiPath 4000 CSTA. The time zone for the RMX is linked with the time zone on the HiPath 4000 Assistant and is configured using the HiPath 4000 Assistant (see Section 6.3.1, “Setting the Time Zone and Summer Time for HiPath 4000 Assistant and RMX”). Whenever the time zone on the HiPath 4000 Assistant is changed, it is also automatically reconfigured for RMX. This also applies to the summer time setting.

6.3.1 Setting the Time Zone and Summer Time for HiPath 4000 Assistant and RMX

During installation of the HiPath 4000 Assistant, its time zone is taken from the HiPath 4000 platform. This means it is then independent of the HiPath 4000 platform.




Configuring the Time Zones

The time zone and summer time are set via the HiPath 4000 Assistant.

Base Administration > Webmin > System Administration "Timezone”

You can set the time zone and summer time by selecting the desired time zone from the Neue Zeitzone (New time zone) list and then clicking the Modify button. The time zone change is effective immediately.

IMPORTANT: The time zone on the ADP should not be changed manually with AMO DATE!

6.3.2 Setting the Time Zone and Summer Time on the Access Point/HiPath 4000 SoftGate

Because the Access Points/HiPath 4000 SoftGates may also be located in a different time zone than the host system, their time zone/summer time can be configured with the assistance of AMO SIPCO and AMO UCSU.

Specify the timeshift of the access point with respect to the host in AMO SIPCO (parameters OFFSET and DIRECT). In addition, you can also specify the parameters for the daylight-saving time adjustment.

CHANGE-SIPCO:TYPE=TCLASS,TCLASS=1,OFFSET=120,DIRECT=WEST,DSTSW=AUTO,MONTHDST=1,WKDAYDST=SO,DAYNODST=FIRST, HOURDST=2,MINDST=30,MONTHNT=1,WKDAYNT=SA,DAYNONT=FIRST,HOURNT=2,MINNT=20;

You then assign the access points to the relevant time classes in AMO UCSU with the TCLASS parameter).

CHANGE-UCSU:UNIT=AP,LTG=<nummer>,TCLASS=1;

Relevant AMOs

AMO Parameter Sprache/Language

Beschreibung/ Discription

SIPCO TCLASS d Zeitklassen-Index

e Time Class Index

OFFSET d Der Parameter OFFSET gibt die Zeitver-schiebung in dieser Zeitklasse in Minuten

an.

OFFSET e The parameter OFFSET defines the time shift of this time class in minutes.



Time SynchronizationConfiguring the Time Zones

6.3.3 Setting the Time Zone for HiPath 4000 CSTA

The virtual machine has regions, UTC time zone etc. The time zone is independent of the HiPath 4000 platform and can be configured using YaST.

RICHT d Der Parameter RICHT gibt die Richtung der Zeitverschiebung an. Eine Verschiebung nach OST ergibt immer eine spatere Zeit,

d.h., der Zeit-Offset wird zur aktuellen Systemzeit addiert. Hingegen wird bei einer Verschiebung nach WEST der Zeit-Offset von der aktuellen Systemzeit subtrahiert,

d.h., es wird fruher.

DIRECT e The parameter DIRECT specifies the direction of the time shift. A shift to EAST

results in a later time, which means that the time offset will be added to the actual

system time. A shift to WEST results in an earlier time because the time offset will be

subtracted from the actual system time.

UCSU TCLASS d Zeitklassen-Index

TCLASS e Time Class Index

AMO Parameter Sprache/Language

Beschreibung/ Discription




Configuring the Time Zones


system_backup_restore.fm

System Backup and RestoreFeature Description

7 System Backup and Restore

7.1 Feature Description

The system backup performed up to HiPath 4000 V5 was part of the HiPath 4000 Assistant Backup Set.

A completely new system backup concept is being introduced with HiPath 4000 V6, which is being offered on the Linux host platform.

Es gibt ab HiPath 4000 V6 also nun zwei unterschiedliche Stellen die Backups abhandeln:

There are now two different locations for handling the backups as of HiPath 4000 V6:

Firstly:

• HiPath 4000 Assistant with the previously described backup-types

and secondly

• the host platform, which is responsible for the system backup.

The system backup contains all needed HiPath 4000 V6 applications including RMX, HiPath 4000 Assistant and CSTA images as well as the configuration data.

This backup set will be stored (default) on the system hard disk.

Each backup set contains a First Install Wizard (FIW) which has to be used for the Restore.

After a successful restore, the HiPath 4000 applications will be started automatically in basic mode. This means only the HiPath 4000 Administration Portal is running/accessible.

In the next step the LAN Wizard has to be started and the eth interfaces must be checked or reconfigured. In case of the restore will be done on a new/different hardware, then you must check the eth lan interfaces and change if necessary.

Use case

• Hard disk crash - restore on new hard disks with preinstalled SLES 11

• Recovery to a previous HiPath 4000 V6 running environment


System Backup and Restore


Service Information

7.2 Service Information

Prerequisites

• On the destination storage location of the system backup kit minimum 8 GB free disc space is required.

• The restore of the new System Backup requires a preinstalled SLES 11 SP1 hard disk.

• During the restore process a SLES 11 SP1 repository (e.g. SLES11 SP1 DVD) must be available.

Restrictions

• The installed license files are not part of the system backup.

• For the time when the HiPath 4000 Assistant system backup rpms are build, the HiPath 4000 Assistant will be shut down. RMX and CSTA stay in service without interruption.

• The backup set of DSCXL2 hardware can only be restored on DSCXL2 hardware and not on a server plattform.

• The backup set of server plattform can only be restored on a server plattform hardware and not on a DSCXL2 harwdare.

• During the system backup is running no “Backup & Restore” via HiPath 4000 Assistant is possible and vice versa.

7.3 User Interface

Actually two different user interfaces are needed:

• Backup is done via HiPath 4000 Administration Portal

• Restore is done via the First Install Wizard

7.4 System Backup

HiPath 4000 Administration > Maintenance > System Backup > Backup



System Backup and RestoreSystem Backup

Figure 15 System backup in HiPath 4000 Administration Portal

Each system backup kit is stored in a separate directory (sysbackup_ YYYY_MM_DD_HH).

Actually the system backup is stored on the local partition /var/opt/sysbackup/ .

IMPORTANT: It is highly recommended to copy the generated system backup from /var/opt/sysbackup/sysbackup_YYYY_MM_DD_HH to an external storage location.

To start the generation of a new system backup push the Button Start System Backup Now.

Figure 16 System backup generation running in HiPath 4000 Administration Portal




System Restore

7.5 System Restore

IMPORTANT: In the HiPath 4000 Administration Portal only the restore procedure is only described. You cannot execute a system restore with the HiPath 4000 Administration Portal.

HiPath 4000 Administration > Maintenance > System Backup > Restore

Figure 17 System restore in HiPath 4000 Administration Portal

7.5.1 Prerequisites

Dependant on which target system the restore will be done, different steps and preconditions are necessary.

General preconditions

• preinstalled SLES 11 SP1

• original/respectively new license files (for HiPath 4000 Assistant/HiPath 4000 Base, HiPath 4000SoftGate, …)

7.5.2 System Restore Scenarios

7.5.2.1 Restore on the same unchanged Target System

No reconfiguration of eth interfaces is needed.

Steps:

• Restore of the system backup (using First Install Wizard).



System Backup and RestoreSystem Restore

• Check the eth interfaces (using HiPath 4000 Administration Portal > System > LAN Wizard).

7.5.2.2 Restore on the same Target System after new SLES Installation

This is the case when e.g. the hard disk crashed and must be replaced.

Following reinstallation of the Linux operating system, it is highly likely that the eth configuration will no longer be compatible wiht the configuration saved in the system backup. The eth interfaces have to be reconfigured in this case.

Steps:

• SLES 11 installation.


• Reconfiguration of the eth interfaces (using HiPath 4000 Administration Portal > System > LAN Wizard).

• Installation of original licence files for CLA.

7.5.2.3 Restore on the same Target System after LAN Card Changes

In this case the udev configuration changes. A reconfiguration of eth interfaces is necessary.

Steps:



• In case that the MAC address in the license file doesn´t match, new license files are needed.

• Installation of new license file for CLA.

7.5.2.4 Restore on a different Target System

After restoring the system backup a reconfiguration of the eth interfaces is always necessary.

Steps:

• SLES 11 installation.




System Restore



• Installation of new licence files for CLA (because of new MAC addresses).

IMPORTANT: DSCXL2 backup only can be restored on DSCXL2 hardware. The same applies to the server plattform.

7.5.3 System Restore via First Install Wizard (FIW)

Prerequisites

• Before starting the installation of the system backup set via FIW the SLES 11 SP1 repository (e.g. DVD, iso image, …) must be available.

• If necessary change the runlevel from 3 to 5.

Procedure

Start the included FIW from the system backup directory (commandline: e.g. ./FirstInstallWizard).

On a preinstalled system it is required to choose the option Install Packages, but remove installed first (necessary for Restore of System Backup).

Figure 18 System restore with FIW - Select option

Confirm with Next.

In the next page the actual system backup deployment is selected.




Figure 19 System restore with FIW - Software package installation

Confirm with Next.

In the next step the stored customer LAN interface and IP addresses can be adapted or changed if necessary.

Figure 20 System restore with FIW - HiPath 4000 configuration options

Confirm with Next.

After finishing the restore procedure in most cases (except restore on the unchanged target system) a reconfiguration of eth interfaces is necessary.

7.5.4 eth Interface Configuration with LAN Wizard (HiPath 4000 Administration Portal)

HiPath 4000 Administration Portal > System > LAN Wizard




System Restore

Figure 21 eth interface configuration with LAN wizard - Hardware platform

Select the apropriate hardware platform and confirm with Next.

Figure 22 eth interface configuration with LAN wizard - customer, IPDA and Atlantic LAN

The eth configuration and the IP addresses have to be checked and modified if necessary.

Confirm with Next.




Figure 23 eth interface configuration with LAN wizard - internal LAN

After the complete configuration press the Submit button even if you didn’t change any parameter within the configuration.

After a few minutes all applications on the host platform should run with the configuration data from the installed system backup.

The last step is to provide the license files for the CLA.

7.5.5 Provide License File for the CLA

Load the license files using HiPath 4000 Assistant under Access Management > License Management.




System Restore


raid_synchronization.fm

Raid SynchronisationLeistungsmerkmalbeschreibung

8 Raid Synchronisation

8.1 Leistungsmerkmalbeschreibung

IMPORTANT: Es wird empfohlen immer zwei Festplatten im HDTR zu haben und diese in einem Raid-Verbund zu betreiben! Der Raid-Verbund bietet einen zusätzlichen Schutz bei Hardware-Fehlern!

Vorteil

Das hat den Vorteil, dass bei Ausfall der aktuellen Festplatte (Hardware-Fehler) eine weitere Festplatte existiert mit der der Betrieb ohne Unterbrechung fortgeführt werden kann.

Nachteil

Der Nachteil eines Raids ist, dass Software-Fehler auf die zweite Festplatte “vererbt” werden.

8.2 Ablauf

1. Schieben Sie eine Festplatte in den oberen Schacht des HDTR. Von dieser Festplatte wird gebootet.

2. Melden Sie sich am HiPath 4000 Administrationsportal an.

3. Überprüfen Sie, ob die Festplatte korrekt eingelegt und gelesen wurde.

Wechseln Sie zu Wartung > Notfall-HD.

Figure 24 HiPath 4000 Administrationsportal > Eine Festplatte im HDTR


Raid Synchronisation


Ablauf

Hier sehen Sie, dass sich im Moment nur eine Festplatte im HDTR befindet. Den Zustand der Festplatte und des HDTR kann man auch an Hand der LEDs am HDTR erkennen.

4. Überprüfen Sie, ob sich im unteren Schacht keine Festplatte befindet (die entsprechende LED ist aus). Schieben Sie die zweite Festplatte in den unteren Schacht des HDTR.

5. Nachdem Sie die zweite Festplatte eingeschoben haben, wird die Seite des HiPath 4000 Administrationsportals entsprechend aktualisiert:

Figure 25 HiPath 4000 Administrationsportal > Zwei Festplatten im HDTR

6. Wählen Sie nun die Schaltfläche Add to softraid um die Raid-Synchronisation zu starten.

Die Raid-Synchronisation wird in in zwei Schritten durchgeführt.

Der erste Schritt dauert nur einige Minuten.

Im zweiten Schritt erfolgt dann die Synchronisation der beiden Festplatten. Da das einige Stunden dauert, erscheint vorher noch die folgende Abfrage:

Figure 26 HiPath 4000 Administrationsportal > Raid-Synchronisation starten

Wenn Sie OK wählen, wird die Raid-Synchronisation gestartet.

LED Bedeutung

Alle LEDs aus Einschub ist leer (keine Festplatte drinnen).

Blaue LED leuchtet und die rote LED blinkt nicht

Festplatte ist im HDTR aber das Raid wird nicht benutzt.

Blaue LED leuchtet und die rote LED blinkt

Festplatte ist im HDTR und wird benutzt und darf nicht entfernt werden.

Table 4 LED-Anzeigen



Raid SynchronisationAblauf

Im HiPath 4000 Administrationsportal sehen Sie nun nacheinander zwei Fortschrittsbalken. In diesen Fortschrittsbalken wird die geschätzte Zeit für die Durchführung angezeigt.

Schritt 1:

Figure 27 HiPath 4000 Administrationsportal > Raid-Synchronisation Schritt 1

Schritt 2:

Figure 28 HiPath 4000 Administrationsportal > Raid-Synchronisation Schritt 2

7. Nach der Synchronisation wird die Seite im HiPath 4000 Administartionsportal aktualisiert.

Das Raid hat nun den Status “OK” und nicht mehr “Critical”.


Raid Synchronisation


Ablauf

Figure 29 HiPath 4000 Administrationsportal > Raid-Synchronisation erfolgreich

8. Nachdem der Raid-Verbund erstellt wurde, können weitere Funktionen aufgerufen werden.

• Entfernen (Remove)

Die entsprechende Festplatte kann aus dem Raid-Verbund entfernt werden.

Sobald die Festplatte entfernt wird, bekommt das Raid den Status “Critical”.

• Notfall-HD erstellen (Create Emergency HD)

Es kann nun eine Notfall-Festplatte erstellt werden (siehe Chapter 9, “Notfall-Festplatte”).


emergency_hd.fm

Notfall-FestplatteErstellen einer Notfall-Festplatte

9 Notfall-Festplatte

9.1 Erstellen einer Notfall-Festplatte

Mit Hilfe des Hard Disk Trays (HDTR) kann eine Notfall-Festplatte erstellt werden.

9.1.1 Voraussetzungen

• Stellen Sie sicher, das sich zwei Festplatten im HDTR befinden und eine Raid Synchronisation bereits erfolgt ist (siehe Chapter 8, “Raid Synchronisation”).

• Bei Duplex muss die Festplatte der DSCXL2 im Einbauplatz 5 synchron zu den Festplatten im HDTR laufen.

9.1.2 Ablauf

1. Melden Sie sich am HiPath 4000 Administrationsportal an.

2. Wählen Sie Im Menü Wartung > Notfall-HD die Schaltfläche Erzeuge Notfall-HD (Create Disaster HD).

Figure 30 HiPath 4000 Administrationsportal > Notfall-HD erstellen

Die Notfall-Festplatte wird erstellt und anschließend wird der Raid-Verbund der beiden Festplatten aufgehoben. Dieser Vorgang dauert ca. 10 Sekunden. Der Status wird im HiPath 4000 Administrationspoartal wiedergegeben:


Notfall-Festplatte

emergency_hd.fm

Erstellen einer Notfall-Festplatte

Figure 31 HiPath 4000 Administrationsportal > Notfall-HD erstellt und Raid-Verbund aufgehoben

Nach erfolgreicher Erstellung der Notall-Festplatte muss diese (unterer Schacht) aus dem HDTR entfernt werden. Bitte beachten Sie dabei die entsprechende LED (darf nicht mehr rot blinken). Heben Sie die Notfdall-Festplatte an einem sicheren Ort auf.

Nach dem entfernen der Festplatte aus dem Schacht des HDTRs wird auch das HiPath 4000 Administartionsportal aktualisiert. Es wird nur noch die verbleibende Festplatte dargestellt.

Figure 32 HiPath 4000 Administrationsportal > Eine Festplatte im HDTR

9.1.3 Fehlersuche

1. Die Schaltfläche Notfall-Festplatte erstellen (Create Disaster HD) erscheint nicht im HiPath 4000 Administrationsportal.

Überprüfen Sie bei einer Duplex-Konfiguration, ob die DSCXL2 im Einbauplatz 5 in Betrieb ist.

2. Obwohl die Schaltfläche Notfall-Festplatte erstellen (Create Disaster HD) angezeigt wird und ausgewählt werden kann, wird keine Notfall-Festplatte erstellt.

Es dauert ca. 4 - 5 Sekunden bis sich das HiPath 4000 Administrationsportal aufsynchronisiert hat. Versuchen Sie es dann noch einmal.


emergency_hd.fm

Notfall-FestplatteEinsatz der Notfall-Festplatte

9.2 Einsatz der Notfall-Festplatte

Einsatzfälle

• System funktioniert nicht mehr - Totalausfall

• Softwarefehler (z.B. korruptes Dateisystem)

Ablauf

1. Schalten Sie das System aus.

2. Entfernen Sie alle Festplatten aus dem HDTR.

3. Stecken Sie die Notfall-Festplatte in den oberen Schacht des HDTR.

4. Schalten Sie die DSCXL2 im Einbauplatz 1 ein.

Daraufhin wird von der Notfall-Festplatte gestartet.

Die Anlage läuft mit dem Softwarestand der Notfall-Festplatte hoch.


Notfall-Festplatte

emergency_hd.fm

Einsatz der Notfall-Festplatte


softwareLOF.fm

Nur für den internen Gebrauch List of Figures

List of Figures 0

Figure 1 LAn interfaces DSCXL2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Figure 2 LAN interfaces of AP 3700 IP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Figure 3 Simplex mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Figure 4 Duplex mode (DSCXL2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Figure 5 Separated Duplex. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Figure 6 Functionality of separated duplex. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Figure 7 Failure in active CC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Figure 8 DSCXL2 board is unavailable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Figure 9 System shut down with HiPath 4000 Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Figure 10 Smart Services Delivery Platform - SSDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Figure 11 Notification Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Figure 12 Time synchronization - overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Figure 13 Date and time module of YaST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Figure 14 Datums- und Zeiteinstellung mit YaST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Figure 15 System backup in HiPath 4000 Administration Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55Figure 16 System backup generation running in HiPath 4000 Administration Portal . . . . . . . . . . . . . . 55Figure 17 System restore in HiPath 4000 Administration Portal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Figure 18 System restore with FIW - Select option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Figure 19 System restore with FIW - Software package installation . . . . . . . . . . . . . . . . . . . . . . . . . . 59Figure 20 System restore with FIW - HiPath 4000 configuration options . . . . . . . . . . . . . . . . . . . . . . . 59Figure 21 eth interface configuration with LAN wizard - Hardware platform. . . . . . . . . . . . . . . . . . . . . 60Figure 22 eth interface configuration with LAN wizard - customer, IPDA and Atlantic LAN . . . . . . . . . 60Figure 23 eth interface configuration with LAN wizard - internal LAN . . . . . . . . . . . . . . . . . . . . . . . . . 61Figure 24 HiPath 4000 Administrationsportal > Eine Festplatte im HDTR . . . . . . . . . . . . . . . . . . . . . . 63Figure 25 HiPath 4000 Administrationsportal > Zwei Festplatten im HDTR. . . . . . . . . . . . . . . . . . . . . 64Figure 26 HiPath 4000 Administrationsportal > Raid-Synchronisation starten. . . . . . . . . . . . . . . . . . . 64Figure 27 HiPath 4000 Administrationsportal > Raid-Synchronisation Schritt 1. . . . . . . . . . . . . . . . . . 65Figure 28 HiPath 4000 Administrationsportal > Raid-Synchronisation Schritt 2. . . . . . . . . . . . . . . . . . 65Figure 29 HiPath 4000 Administrationsportal > Raid-Synchronisation erfolgreich . . . . . . . . . . . . . . . . 66Figure 30 HiPath 4000 Administrationsportal > Notfall-HD erstellen . . . . . . . . . . . . . . . . . . . . . . . . . . 67Figure 31 HiPath 4000 Administrationsportal > Notfall-HD erstellt und Raid-Verbund aufgehoben. . . 68Figure 32 HiPath 4000 Administrationsportal > Eine Festplatte im HDTR . . . . . . . . . . . . . . . . . . . . . . 68


List of Figures Nur für den internen Gebrauch

softwareLOF.fm


softwareLOT.fm

Nur für den internen Gebrauch List of Tables

List of Tables 0

Table 1 Corresponding products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Table 2 Hard disk layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Table 3 HiPath 4000 Assistant - Customer Account Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Table 4 LED-Anzeigen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64


List of Tables Nur für den internen Gebrauch

softwareLOT.fm


softwareSIX.fm

Nur für den internen Gebrauch Index

Index Z

AAccess Management 30Applications 22

Bbackup 53Base Administration 31

CConfiguration Management 32Configuring the time 47

DDiagnostics 33Duplex 10

EExpert Mode 31

HHard Disk 24Hardware Architecture Table 24Hardware Configurations 10HiPath 4000 Assistant Applications 29HiPath 4000 in the customer LAN 7

IIP addresses, checking 8

LLicense packages 21Loading Tables 22

NNotification Mechanism 37

PPortlist for Customer 22

Rrestore 53

SSelections 22Simplex 10Software Management 29Survivability Unit

AP 3700 IP 8

HiPath 4000 SoftGate 8System backup 53System Management 32System restore 53

TTime Synchronization 47

UUsage Scenarios 37User Accounts 34


Index Nur für den internen Gebrauch

softwareSIX.fm


Documents

Documentation - Add docshare01.docshare.tips to …docshare01.docshare.tips/files/24603/246038920.pdfDocumentation HiPath 4000 V6 System Components - Software Service Documentation