DE102010005331A1 - Method for safe switching back of data center after failover during financial data transaction, involves indicating that primary data center is again ready for operation after failover - Google Patents

Abstract

The method involves indicating that a primary data center (DC1) is again ready for operation after failover, where the status of the primary data center is indicated by a secondary data center (DC2). A client (CLA) is prompted to run out of service. A synchronization is performed by a configuration data or transaction data between the primary and secondary data center. The primary data center is switched back by the client after the synchronization. An independent claim is also included for a network structure for safe switching back of a data center after failover.

Description

The invention relates to a method for safely switching back to a first data center after failover by a second data center and a network structure operating thereafter. In particular, the invention relates to a method for failover and for safely switching back a client or a cluster of clients, which are designed as transaction terminals, in particular as self-service terminals (eg as ATMs, bank statement printers or transfer terminals), and preferably with connected to the first data center and are connected to the second data center only for failover, with synchronization data is exchanged between the data centers.

Especially in the area of transaction terminals and networks, which are designed for financial transactions, usually the transaction terminals can be connected to more than one data center or data center in order to have sufficient failover in the event that the preferred data center fails. At least one of the other data centers then as a backup data center and takes over the tasks of the preferred data center for the downtime. It is known that for this purpose configuration and transaction data of the connected terminals must be synchronized between the two data centers. However, if the two data centers or data centers are very far apart from each other, synchronization problems can arise since the synchronization processes are generally very time-critical. This applies in particular to high-availability clusters (high-availability clusters, abbreviated to HA clusters, see also http://de.wikipedia.org/wiki/Computercluster ), in which constantly running on all nodes services and thus a real active-active operation (Active / Active) is possible.

Known database management systems also include corresponding synchronization mechanisms, such. For example, Oracle RAC (Oracle Real Application Cluster, ^Oracle® is a registered trademark of Oracle Corporation, Redwood Shores, Canada). That up http://de.wikipedia.org/wiki/Oracle Oracle RAC described in RAC provides resilience by allowing multiple nodes in a cluster to access the same database and provide database services to client machines. If one of the nodes fails, the others take over its functionality. It has been found, however, that these conventional synchronization mechanisms only work reliably if the affected databases are not too far apart from each other, ie not more than 25 km apart. In many network architectures, however, data centers and their databases are networked with each other, which are significantly farther apart, so that sometimes several thousand kilometers have to be overcome. The use of conventional mechanisms can no longer be successful, especially in active-active operation; Secure synchronization then requires a great deal of effort, including with regard to the hardware to be used (including special optical waveguides, such as, for example, dark fiber), or even appears to be impossible.

Network architectures of the type mentioned above, in which preferred financial transaction terminals, in particular ATMs (ATM: Automatic Teller Machines) are connected to data centers are z. B. in the US 2002/0147702 A1 or the DE 600 33 895 T2 described. However, the issue of securely switching back to the preferred data center after failover by a remote backup data center is not addressed there.

The object of the invention is to propose a method for securely switching back to a first data center after failover by a second data center, which can be used even in data centers located far from each other without losing transaction data. It is also intended to propose a network structure carrying out the method. In particular, the method should be applicable to financial transaction terminals and associated data centers.

The object is achieved by a method having the features of claim 1 and by a network structure for carrying out the method with the features of the independent claim.

Accordingly, a method is proposed in which at least one transaction terminal is connected as a client to the second data center during a downtime of the first data center and is switched back to the first data center at the end of the downtime by:
the second data center is indicated that the first data center is ready for use again;
the client is caused to go out of service;
a Synchronization of configuration and / or transaction data between the first and the second data center is performed; and
upon completion of the synchronization, the client is caused to switch back to the first data center.

As a result, the respective client is briefly put out of operation to safely perform the synchronization of configuration and / or transaction data in this time and only to reactivate the client when the synchronization is completed.

If there are multiple clients or transaction terminals that have the same preferred data center and are to be switched back to this, one terminal after another is advantageously put out of service and reactivated after successful synchronization or resynchronization.

In the preferred applications, the at least one client is a self-service terminal, in particular an ATM, bank statement printer, transfer terminal, which is preferably connected to the first data center and is connected to the second data center only for failover.

Further advantages will become apparent from the dependent claims.

The invention will now be described by way of example with reference to the accompanying drawings, in which:

1a / b show a network structure with two data centers and several associated financial transaction terminals;

2a / b illustrate normal operation, including making configuration changes and processing transactions;

3a Figure-d illustrate a failure situation with subsequent recovery in which the preferred data center will fail for a period of time; and

4 shows a flowchart for the inventive method.

The 1a shows in the form of a block diagram a network structure with two data centers DC1 and DC2 and several associated financial transaction terminals in the form of ATMs, which are connected as clients CLA and CLB with the data centers. The first clients CLA have as a preferred data center, the first data center DC1 and access only for failover to the second data center DC2, which thus serves as a backup data center for the client CLA. Accordingly, the first client CLA or the cluster of the first clients is normally connected via a data line L to the first computer center DC1. The data centers or data centers are located at different locations (locations), which can be very far apart. In the event of failure of the first (preferred) data center DC1, a connection (fall back connection) to the second data center DC2 is established via the data line L '. For the clients CLB or terminals of the other cluster, the situation is reversed, ie the data center DC2 is the preferred one and is only temporarily replaced by the data center DC1 in the event of a failure. The data centers DC1 and DC2 can be interconnected (for synchronization and the like) via a data connection DCL and are in turn connected to a backend system BES, here the booking system. The 1b shows the described network architecture in more detail, wherein on each page only one client CLA or CLB is shown as an example. The others 2a /Federation 3a -D build on the in the 1a / b shown basic structure and reflect different situation.

Based on 2a / b is described below the normal operation in which none of the data centers fails:
In normal operation, the processes for configuration changes run on both sides of the application server ASC1 or ASC2, which then transmit the configuration changes to the respective databases. This principle is also called "distributed database transactions". This ensures that all data centers, such as here. DC1 and DC2, work with the same configuration. The essential commands or operations are: ws for "write sync", rl for "read local" and cc for "config changes". In the normal situation, both installations run more or less independently of each other. The client CLA has the data center DC1 as the preferred data center and remains connected to the servers (cluster of PC / E servers) within the first data center DC1. Processes, such as For example, clearing or settlement transactions (clearing or settlement) are also performed by these servers. However, as a backup data center, the data center DC2 also has the master data of the client CLA, in order to know that this client is to be treated as a backup client for the data center DC2. All active clients CLA are displayed as part of a current progress bar on the administrator console (Admin Console) of the data center DC1. On the administrator console of the other data center DC2, the clients CLA are displayed with the status "Standby". The administrator consoles are part of the respective database management system DBMS1 or DBMS2.

• – Es wird ein zusätzliches Modul „Sync Master Data” auf den Rechenzentren eingesetzt, das eine Aktualisierung (Update) der Master-Daten selbst und der Konfiguration an den entfernten Orten durchführt mit Bestätigung (Acknowledge) des entfernten Cache-Systems. Das Modul läuft auf den Rechenzentren und dient dazu die Stammdaten synchron halten.
• – Alle Programmkomponenten (AdminBeans) in dem PC/E Server Core, welches die Stammdaten oder Konfiguration schreibt, weisen optional die „Sync Master Data” Funktionalität auf.
• – Der PC/E (ProClassic/Enterprise) Database Persistance Lager muss in der Lage sein, das „Sync Master Data” Modul aufzurufen für jeden Save oder Update Anforderung eines Werteobjekt, wenn es erforderlich ist.
• – Im Fall eine dualen Änderung bzw. Modifikation zur selben Zeit, was zu einem Konflikt führt, wird diejenige Save Operation unterbrochen und wiederholt, die den Konflikt erkennt.
• – Jede PC/E Instanz besitzt einen eigenen „nur lokalen” Konfiguration für u. a. folgende Attribute: • Eigene Rechenzentrumskennung (Own Location identifier) • Ausfallrechenzentrumsadresse und Kennung (Backup Location address and identifier) • Sync status • ....
• – Die Workstation Master-Daten besitzen ein Feld für das bevorzugte Rechenzentrum (primary Location bzw. Datacenter site identifier), der alle Prozesse in die Lage versetzt, zu bestimmen, ob der Client defaultmäßig zur aktuellen Instanz gehört. Auch muss das Backup Rechenzentrum (zweite Location identifier) konfigurierbar sein.
• – Die Admin-Konsole zeigt die im Standby befindlichen Clients an (Workstations, bei denen das bevorzugte Rechenzentrum (primary Location identifier) ungleich dem aktuellen Rechenzentrum ist.
• – Es wird ein zusätzlicher Befehl (s. SLC in 3c) verwendet, um den Client zu zwingen, zurück vom zweiten Rechenzentrum zum ersten Rechenzentrum zu schalten.
• – Die Admin-Konsolen werden über einen Link miteinander verbunden, um eine Anmeldung an beiden Instanzen zu gewährleisten. Dadurch ist es möglich, sich an verschiedenen Admin-Konsolen über einen Browser (TAB Browser) anzumelden (LogIn).
• – Das Modul zur Synchronisierung von Transaktions- und Statusinformationen

The configuration and changes of master data (master data) are as follows:
All changes within the configuration and the master data are in a JTA Java transaction written in the database management systems DBMS1 and DBMS2 both data centers DC1 and DC2. The following changes must be made for the PC / E Server:

• An additional module "Sync Master Data" is used on the data centers, which performs an update of the master data itself and the configuration at the remote locations with acknowledgment of the remote cache system. The module runs on the data centers and serves to keep the master data synchronized.
• - All program components (AdminBeans) in the PC / E Server Core, which writes the master data or configuration, optionally have the "Sync Master Data" functionality.
• - The PC / E (ProClassic / Enterprise) database persistence warehouse must be able to invoke the "Sync Master Data" module for each save or update request of a value object, if required.
• In the case of a dual change at the same time, resulting in a conflict, the Save operation that detects the conflict is interrupted and repeated.
• - Each PC / E instance has its own "only local" configuration for, among others, the following attributes: • Own own location identifier • Backup location address and identifier • Sync status • ....
• The workstation master data has a field for the preferred data center (primary location or data center site identifier), which enables all processes to determine whether the client by default belongs to the current instance. Also, the backup data center (second location identifier) must be configurable.
• - The Admin Console displays the standby clients (workstations where the primary location identifier is different than the current datacenter).
• - An additional command (see SLC in 3c ) is used to force the client to switch back from the second data center to the first data center.
• - The Admin consoles are linked by a link to ensure logon to both instances. This makes it possible to log in to various admin consoles via a browser (TAB Browser) (LogIn).
• - The module for the synchronization of transaction and status information

Concerning the events and commands (Events and Commands) the following should be considered:
In general, events are handled locally by each instance. The backend status or device status is not forwarded to the other instances (routing). Therefore, the client must send the current status information at any time when it is reconnected to an instance to lock (disable) transactions depending on the device list.

Forwarding events to a separate server, such as Proview is also run separately from each data center. Therefore, the system must be able to receive the events from the two different locations.

Commands can also be handled locally (only for the currently connected clients). For better usability, the PC / E Admin console can have a button or button to easily switch to the Admin console, which can issue the command to the client.

The difference is especially in the treatment of restrictions. Each restriction must be forwarded to the second location. In the case of recovery of the normal operation, the current second location limitation record must be synchronized with that of the first location (primary location).

As for a scheduled server service or timer service, it is treated locally and performs all tasks only for those clients that are currently connected to the site. Clients whose first location (primary location) is located on a different instance will not be treated unless there is a special need for it.

As far as the server services are concerned, they have by default (by default) influence on those clients that are not in "standby" mode. For example, the Workstation Timer Service will handle only own and connected systems.

As far as the journal is concerned, it is always written in the current location. To enable a cross-search across data centers, a second journal data source configuration is used. This allows a shared search query for journal information for all clients connected to both data center sites.

As far as the processing of transactions (Transaction Processing) is concerned, in particular with reference to 2 B to say the following:
The processing of transactions TA is performed only within each PC / E server instance and not across the data center site. A transaction or even a session that has been started at a site (for example, data center DC1) must be completed and terminated at the same site. In the event of a failover, the client (here, for example, CLA) will start a new session on the new location (that is, on data center DC2), but the session of the previous location must be completed in a defined manner.

• • aktuelle Beschränkungen (restrictions)
• • Server-seitige Zähler (counters), die nicht von dem Client während des Startup bereit gestellt werden
• • Server-seitige Transaktions-Informationen, die erforderlich sind für die zweite Location (z. B. customer daily limits)
• • Geldautomaten- bzw. ATM servicing transaction (add cash, remove cash etc.) Informationen für die Zähler und Clearing-Information

The following information is provided as part of an online mechanism for the remote location:

• • current restrictions
• • Server-side counters that are not provided by the client during startup
• • Server-side transaction information required for the second location (for example, customer daily limits)
• • ATM or ATM servicing transaction (add cash, remove cash etc.) information for the counters and clearing information

This task is performed by a separate module to optimize the amount of data and communication latencies. The module runs on the data centers and transmits the said information via the data connection DCL.

For Reporting / Journal Appender, it is useful for reporting and parsing to configure a common centralized system (either an online system or a separate database). All locations or systems DC1 and DC2 write the information with a unique identifier into a table containing the workstation and transaction information. All data can only be written locally, but this would only allow local queries.

In addition, with reference to the 3a -D describes the case where one of the data centers fails within the network structure:
The 3a illustrates the case in which the preferred data center DC1 fails or the connection with the client CLA is disturbed. For active-active operation, the CLA client constantly saves what are known as restart data, that is, some backup data about the transactions that have been started in each case, such as: For example, the restart data RST1 for transaction TA1. In case of failure or malfunction z. For example, the client CLA will be attempted to complete the transaction TA1 with the preferred data center DC1 based on the stored restart data RST1. For this purpose, the client CLA first tries to reconnect to the preferred data center DC1; the other data center DC2 remains unaffected. The invention is based on the principle that each transaction must be completed at the data center where it started. For example, the transaction TA1 has been started (initiated) on the first data center DC1. Therefore, this transaction TA1 is completed on the first data center DC1. If the completion is successful, this leads to an OK, otherwise to a Cancel. Due to this principle z. For example, in the event of a failover, the session data is not transferred from one data center (eg DC1) to the other (DC2) (eg via the connection DCL). All you need to do is transfer data that allows the data centers to monitor client operations. This information includes information about restrictions and / or counter readings. As a result, the amount of data transferred between data centers is significantly reduced. In order to better comply with this basic rule, each client also creates a file or container for each data center, in other words two containers C and C '(s. 3b ), in which he stores the restart data RST1 or RTS2.

The 3b now shows the situation that the first data center DC1 has failed and already a second transaction TR2 has been started with the second data center DC2. In this case, the client CLA has locally stored both backup data RST1 for the first transaction TA1 and backup data RST2 for the second transaction TA2, but in different areas or containers C or C '. The first transaction TA1 can only be finalized with the first data center DC1 since it was started with this data center. The second transaction TR2 can be fully executed and finalized with the second data center DC2, this data center working as a backup service point for the client CLA. The second computer center DC2 constantly checks whether the first data center DC1 is online. This is in the 3b using the query col "check online" illustrates. As long as the first data center DC1 is not online, the second transaction TA2 and subsequent ones are handled via the data center DC2.

This means that if one of the data centers (eg DC1) is unavailable or not available, the affected clients (in this case CLA) start a connection attempt with the other data center (here DC2). All configuration and master data are already available on the second location. During this period, all configuration changes are blocked.

For emergencies, there is a special configuration change mechanism that is not replicated. This means that these changes must be made manually on the second data center.

The client will first try to complete the transaction at the current data center location. If this fails, the current customer session is aborted and the restart for this transaction is saved on the client (see TA1 in 3a ). The client will switch to the second location and run the normal startup sequence to log in to the PC / E Server instance (including device status and meter information).

The client will now know and tell the server that a transaction is still pending on the first location. Also, the client must ensure that the old restart data is preserved in a secure manner to complete this transaction as soon as the data center is online again, and the client will then switch back.

The 3c illustrates the situation that the preferred data center DC1 goes online again. DC1 is ready for use again (see also step 109 in 4 ). This is indicated by the DC1 (step 110 in 4 As soon as the second data center DC2 detects this (query COL "check online"), a synchronization STD of transaction data ("Sync Transaction Data") can be carried out (steps 120 - 140 in 4 ). To ensure that, starting from the client CLA, no further transactions are initiated or processes are initiated which could impair the synchronization, the data center DC2 first sends an instruction or an OOS command "out of service" to the client in a first step "1" CLA to put it out of operation for a certain period of time (see also step 120 in 4 ). Then, in a second step "2", the actual synchronization STD is performed (step 130 in 4 ). When the synchronization with the first data center DC1 is completed, the second data center DC2 sends a command SLC "switch location command" to the client CLA. This activates or activates the client CLA again (step 140 in 4 ). The client CLA can then reconnect to the preferred data center DC1 in order, inter alia, to finalize the still open transactions (here TA1).

• 1) Verarbeiten am aktuellen Ausfall-Knoten (default): Die Transaktionen, die auf der zweiten Location verarbeitet werden, werden auf der zweiten Location aufgearbeitet (cleared) und abgeschlossen. Falls erforderlich, werden einige Transaktions-Informationen in zusätzlichen oder eigenen Tabellen gespeichert, um sie an den ersten (primary) PC/E Server für diese Workstation zurück zu synchronisieren.
• 2) Speichern und Weiterleiten: Die Aufarbeitungs- bzw. Clearing-Information (auch EndOfDayProcessing) wird gespeichert, bis die erste Location wieder Online ist und wird dann für spätere Verarbeitung resynchronisiert.

The treatment of transaction clearing data can be done in the following ways:

• 1) Processing at the current default node (default): The transactions that are processed on the second location are processed (cleared) and completed on the second location. If necessary, some transaction information is stored in additional or custom tables to synchronize back to the first (primary) PC / E server for that workstation.
• 2) Saving and forwarding: The processing or clearing information (including EndOfDayProcessing) is saved until the first location is online again and then resynchronized for later processing.

In other words, a separate clearing is also performed to merge information about all transactions of a client, regardless of which data center they were run on. This is preferably done on the preferred data center (master).

The 3d illustrates a finalization on the data center DC1, namely the finalization of the transaction TA1, which is started on just this data center DC1, but could not be completed (see also instruction or operation fin). During a failover (s. 3b ) due to failure of the first data center DC1 all new transactions (eg TA2) have been started on the replacement data center DC2 and will be completed on this.

A client that was able to successfully open a connection to the second location will not switch back to the first location until it receives a particular server command, namely the SLC "switch location command" command. This ensures server-side a defined workstation status.

As soon as the PC / E instance is contacted by one client in a failover scenario, the PC / E server will try to connect to the other location, namely the query COL "check online". Only when the communication is restored will the second server try to move the clients back to the first location. As an alternative or additional feature, the first location may contact the second location to trigger the switchback.

In this case, the server will also receive a message "Location switching not allowed" as Issue a limit for all clients that have treated the server as the first server. It is necessary to avoid switching clients if the data can not be resynchronized to a location that is currently powered off or down (down). If the location is back, not only the data of the backup client but also the current data must be first resyncated (see also 3b / C).

The failure recovery can thus be carried out as follows (see in particular 3c ):
As soon as the client's first location is online again (here DC1 for client CLA), the first location will try to contact the backup location (here DC2). As soon as the connection between both clusters has been established (here via DCL), the second location sends the transaction data to the first location.

For this purpose, the client (here CLA) goes out of operation for a short time (see 3c step "1" with command "out of service"), in which case all storage and forwarding data are resynchronized (see step "2" STD) and finally the client receives the command to switch back to the first location (see FIG. see step "3" with command "switch location command").

If several clients are active (Cluster CLA in 1a ), then this sequence can also be carried out in succession for each client. The clients are then rerouted consecutively, since the stored transaction data must be forwarded to the second location in advance. Thereafter, the local processing can be continued in the normal way.

In case the client has pending restart data for the first location, a normal error handling is performed to also clean up the session information on the server.

The clients which have the first location in the data center DC2 (in this case the clients CLB) will likewise forward the required transaction counter data in order to enable a switchover to the data center DC2. This is done by removing or overriding a specific "no location switching allowed" restriction. This ensures that the required data of the data center clients DC2 are resynchronized during the downtime of the data center DC1 before a client uses this data center DC2 as a backup.

This means that after forwarding the backup client data from the data center DC2 back to the data center DC1 and after updating the data from the data center DC2 originating client data to the data center DC1, the normal data processing sets itself.

As far as continuity (business continuity) is concerned, in the event that it is not possible to reactivate the first or preferred data center (here DC1), the first location of a client can be switched over. The new preferred location can either be the existing backup location (here DC2) or a completely different data center. Therefore, by means of a configuration export, a way is provided to build a new location based on the existing master data and configuration.

For the latency of the cross-connection between the data centers, the following should be said:
Since the invention maintains at least two instances in different data centers, it is also necessary to handle the network issues in the cross-link. If the network interconnect were completely down, this would be considered a disaster for the data centers, unless the failover process described above were available. If synchronization transaction data should not be replicable for the second location, the client will first receive the "no location switch" restriction. The restriction is an indicator of the re-synchronization process of first updating the second location before removing the restriction. This treatment has also been inserted because a customer transaction would not be affected by the synchronization process itself.

In summary, and in particular with reference to the 3c and 3d It must be said that in all these cases a fail-safe synchronization STD is required between the participating data centers (here DC1 and DC2). In order not to impair the synchronization, the client CLA or the affected clients are temporarily put out of order one after the other. The duration is essentially the data sync latency, less than 1 minute. Accordingly, the invention is particularly suitable for Active / Active operation at remote data centers. However, other forms of operation, such as Active / Passive or Active / HotStandby, which are applied to remote data centers, result in significantly longer downtimes of several hours and can take up to half a day to a full day.

The here proposed decommissioning of a backup client (here CLA) by the backup data center (here DC2) can be carried out sequentially with multiple clients.

The invention can preferably also be used in release changes.

LIST OF REFERENCE NUMBERS

CLA, CLB

Transaction terminals as clients accessing the network structure

DC1

first data center (preferred by client CLA)

DC2

second data center (as backup for client CLA)

L, L '

Data connections between clients and data centers or the associated servers

LB

Load balancer

DCL

Network connection (cross-connection between the data centers)

ASC1, ASC2

Cluster of servers (Application Server Nodes)

DBC1, DBC2

Cluster of databases

DBMS1

Database Management System (or Admin Console) for DC1

BES

Backend system (here: posting system)

JTA

Java Transaction

TA1, TA2

transactions

HOURS

Sync Transaction Data

DOS

Command "out of service"

SLC

Command "switch location command"

QUOTES INCLUDE IN THE DESCRIPTION

This list of the documents listed by the applicant has been generated automatically and is included solely for the better information of the reader. The list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions.

Cited patent literature

• US 2002/0147702 A1 [0004]
• DE 60033895 T2 [0004]

Cited non-patent literature

• http://en.wikipedia.org/wiki/Computer_cluster [0002]
• http://en.wikipedia.org/wiki/Oracle [0003]

Claims (7)

Procedure ( 100 ) for safe switching back to a first data center (DC1) after failover by a second data center (DC1), wherein at least one transaction terminal as a client (CLA) to the second data center (DC2) during a downtime of the first data center (DC1) is connected and back to the first data center (DC1) after the end of the downtime, characterized by the following steps: the second data center (DC2) is informed that the first data center (DC1) is ready for operation again (step 110 ); the client (CLA) is caused to go out of action (step 120 ); a synchronization (STD) of configuration and / or transaction data is performed between the first and the second data center (step 130 ); Upon completion of the synchronization (STD), the client (CLA) is caused to switch back to the first data center (DC1) (step 140 ). Procedure ( 100 ) according to claim 1, characterized in that the at least one client (CLA) is a self-service terminal, in particular an ATM, account statement printer, transfer terminal, which is preferably connected to the first data center (DC1) and only for failover with the second data center (DC2 ) is connected. Procedure ( 100 ) according to claim 1 or 2, characterized in that the data centers (DC1, DC2) and the associated databases (DBC1, DBC2) are operated in the active-active mode. Procedure ( 100 ) according to one of the preceding claims, characterized in that a plurality of transaction terminals are switched back as a cluster of clients (CLA) to the first data center (DC1) by causing one client (CLA) after the other to go out of service ( step 120 ) Procedure ( 100 ) according to one of the preceding claims, characterized in that for each transaction (TA1, TA2) a backup data record (RST1, RST2) is locally stored at the client (CLA), the respective backup data record (RST1) being stored in a first data container (C). is stored if the associated transaction (TA1) is executed with the first, preferred data center (DC1) or is stored in a second data container (C ') if the associated transaction (TA2) with the first preferred data center (DC2) is stored. is performed. Procedure ( 100 ) according to one of the preceding claims, characterized in that when the second data center (DC2) is displayed over a prescribable period of time that the first data center (DC1) is not ready for operation again, the client (CLA) as the preferred data center, the second data center (DC2 ) or another data center. Network structure for performing a method according to one of claims 1 to ... with a first data center (DC1) at a first location and at least one second data center (DC2) provided for failover of the first data center (DC1) at a second location is, wherein at least one transaction terminal as a client (CLA) to the second data center (DC2) during a downtime of the first data center (DC1) is connected to be switched back to the first data center (DC1), after the end of downtime in the second data center (DC2) sends a query (COL) to the first data center (DC1) at predeterminable time intervals in order to query whether the first data center (DC1) is ready for operation again; that the second data center (DC2) sends to the client (CLA) a command (OOS) to cause the client to go out of service; that the second data center (DC2) with the first data center (DC1) performs a synchronization (STD) of configuration transaction data via a data connection (DCL); and upon completion of the synchronization (STD), the second data center (DC2) sends to the client (CLA) another command (SLC) to cause the client to switch back to the first data center (DC1).

Images