Skip to end of banner
Go to start of banner

CME Group Front-End Clearing Applications

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

The following section describes Clearing Disaster Recovery (DR) environment processing for CME Group front-end Clearing applications.

CME ClearPort

Through CME ClearPort, a front-end clearing application that offers a set of flexible clearing services open to OTC market participants, customers can write trades directly into the CME ClearPort API or submit trades for clearing via a web-based graphical user interface.

Note: CME ClearPort disaster recovery events are handled in the same manner regardless of whether customers submit trades via the web-based GUI or the ClearPort API.

Normal Production Processing Environment

The following figure illustrates a normal CME ClearPort production processing environment.

 

Note: CME ClearPort is a web-based application, and therefore the environment to which you connect (production vs. disaster recovery) is transparent to the user.

Disaster Recovery Event

Disaster Recovery events are categorized into Site, Staff, or Systems. In the case of CME ClearPort, a Site DR event would mean that the location of the CME ClearPort support staff was unavailable. In a Staff DR event, the Operations or Technology side would be unavailable, and a Systems DR event involves the loss of the CME ClearPort environment due to either a hardware failure or the loss of a data center.

When CME Aurora experiences a DR event, CME Clearport remains unavailable while the CME NYDC environment is being established.

DR Event Notification

Using an automated messaging tool, the CME Group Global Command Center (GCC) uploads a list of CME ClearPort contacts. The CME ClearPort team provides GCC management with text explaining the disaster event, and that text is reviewed, edited (if necessary), approved, and dispatched to the email addresses associated with the contact list.

GCC dispatches DR-related messages to the email addresses provided by customers when creating their CME ClearPort IDs. These messages are provided to ClearPort users regardless of whether they are currently logged into ClearPort.

Note: Disaster event messages are not routed to the CME ClearPort front end.

Recovery Time Frames

As designated in the related Service Level Agreement (SLA), CME Group attempts to resolve CME ClearPort disaster recovery events within a 2 hour time frame. Once CME Group determines the event has been resolved and CME Aurora is available, ClearPort users must re-enter their login.

After a DR event resolution, and prior to CME Aurora availability, applicable databases must be brought up and related applications re-started.

Disaster Recovery Environment

ClearPort Clearing is hosted in CME Aurora and the disaster recovery environment is in CME NYDC. CME NYDC is activated only after a disaster recovery event occurs.

CME Aurora and CME NYDC are duplicate environments where the same applications, servers, and databases are available. These environments are replicated throughout the day to ensure data can be more easily recovered.

When the CME Aurora environment is unavailable and the CME NYDC environment has been established, CME ClearPort users can log directly into CME NYDC using their CME Aurora login credentials.

Note: The disaster recovery environment offers all the same functionality as the production environment.

Transition to DR Environment

The following rules apply when transitioning to the DR environment:

  • The URL by which ClearPort users connect to the CME ClearPort Login page (https://services.cmegroup.com/cpc/) is set for Global load balancing. Therefore, users are dynamically redirected from CME Aurora to CME NYDC during DR testing.
  • ClearPort users must log into CME NYDC after being redirected.
  • CME NYDC and CME Aurora offer the same functionality to ClearPort users.
  • ClearPort customers using an IP, such as CME Aurora IP 164.74.122.29, would (for example) have to connect to CME NYDC IP 204.10.15.11 during DR testing.
  • CME NYDC must be brought up after a DR event prior to the redirect from CME Aurora.
  • Trades that are in-flight at the time of a DR event must be re-submitted in the DR environment.
  • When hard coding to an IP Address, you will not have the benefit of auto-recovery via the CME NYDC, but must instead manually point to the CME NYDC.
  • No labels