Failover Behavior: Secondary CME Gateway

Overview

Secondary CME Gateways offer traders the
opportunity to continue trading should one or more routes to the CME Group fail.
When a CME Gateway fails in a failover environment during trading
hours, all current orders remain as working orders in the market

Note

You can use secondary, redundant CME Gateways
under the following conditions:

Each has a unique exchange-flavor.

You do not repeat the member parameter in any [order_session_#]
sections in the hostinfo.cfg files on other CME Gateways.

When you set up secondary CME Gateways on a network, traders
can log into another CME Gateway to continue trading if the CME Gateway fails.

After reconnecting to the CME Group in this manner, traders
have no access to their current working state or position in the
market (i.e., historical information). This information remains
on the failed TT Gateway in its log and table files.

Note

If you intend on installing secondary CME Gateways
for disaster recovery purposes, traders must use unique Member IDs
when logging into the different TT Gateways. This is a CME Group restriction.
For example, if trader Jim wants access to the exchange through CME -A
and CME-B, he must have a Member ID for CME-A and
a different Member ID for CME-B. In this manner, his login
on each TT Gateway is different.

Gateway Failover Behavior

After a trader closes and then reopens
X_TRADER® and then logs into the alternate CME Gateway, the TT system
exhibits the following behavior:

Fills: X_TRADER® does not have access to any fills
that occurred previous to the trader connecting to the secondary CME Gateway because
the *.bof files
do not hold the fills for the new trader.

Orders: After traders reconnect, they can submit orders.
However, they do not have access to any active orders that were
in the market at the time of the previous connection being lost.
This information is on the failed TT Gateway.

Secondary Gateway Recovery: Software

Secondary Gateway Recovery: Hardware

Example 2: Unsuccessful Failover

Having recovered from the hard drive
crash in the previous Example Scenario 1 – Single CME Gateway, Quick
Financial Services (QFS) now has two CME Gateways (referred to as
A and B) conforming to the setup criteria for Redundant CME Gateways.
During the day, the exchange connections on gateway A fail. Gateway
A immediately loses its connection to the exchange and shuts down.
All traders on gateway A lose their connection to the exchange and
gateway A displays as red in Guardian across the network. Prices
become stale, traders stop receiving fills, and they are unable
to trade.

Jim first documents his position. With his documented position
in hand, Jim calls CME Group and cancels all outstanding orders.
He then closes X_TRADER®, reopens it, and logs into gateway B to
continue trading. Jim already has previously saved workspace on
this gateway and is not prompted to convert. When Jim logs into
gateway B, none of his fills or orders refresh. He does not have access
to his historical fills. He resumes trading.

The IT staff at QFS restarts gateway A. Traders can begin
logging into gateway A, and trading continues as normal. However,
if a trader submits orders on gateway B, then logs off B and into
gateway A, that trader does not have access to trading activity
(orders and fills) managed by gateway B.

Example 3: Unsuccessful Failover

QFS has two TT Gateways (called A and
B) with 40 traders – 20 traders on each gateway. During trading
hours, software on gateway A fails. All 20 traders using that gateway
begin logging into gateway B. However, trading is particularly heavy that
day and the software on gateway B begins experiencing noticeable
latency.

To resolve this situation (latency caused by heavy volume)
from occurring in the future, QFS calls CME Group and orders three
more SLE configuration connections. QFS also calls TT for installation
of three additional TT Gateways. This provides better failover and
supports future growth of the company.