The primary On-Line Transaction Processing (OLTP) database is the most
critical element of the .org registry provisioning function. Because of its
critical nature, the primary OLTP database must be designed and built with
several critical elements considered.
- Performance. The proposed OLTP database is able to provide fast
response. Current SLA requirements of 3 seconds for CHECK functions and 5
seconds for ADD functions are not sufficient. Any database not designed to
process a transaction in less than 500 milliseconds can be expected to have
difficulty handling peak periods. Critical to meeting performance
requirements is keeping the minimal amount of data necessary in the OLTP
database. The proposed OLTP database (which is currently supporting the .org
registry) provides a well thought out archiving process that far exceeds
these requirements.
- Capacity. The proposed .org database is able to process more than
300,000 transactions per minute with 5,000 transactions per second or more
during peak and/or land rush periods. It is also designed and tested to
accommodate more than 100 million registrations.
- Scalability. The proposed .org database is designed to scale beyond
current registration levels. Just as quickly as registration volumes have
been decreasing, they could turn around and begin rising. Even low
registration volumes are no indication of potential transaction volumes.
- Reliability. The success of any TLD registry depends on the quality
of its service. In order for the Internet community to embrace (or continue
to embrace) a TLD, reliability of service and data integrity are of
paramount importance. The proposed .org database has a well-established
history of providing both service reliability and data.
- Security. If the primary OLTP database is susceptible to
unauthorized intrusions, the stability of the entire TLD is at risk. But
security is more than just providing protection against hackers. Section
C17.9 discusses other critical elements of security in detail and describes
how security requirements have been implemented.
- Recoverability. With all hardware and software systems, failures
are not a matter of "if", but a matter of "when".
Therefore, all risks and contingencies must be considered. UIA recognizes
that recoverability starts with the design of the database and continues
into the hardware architecture, the software architecture, and even the
underlying supporting facilities infrastructure.
- Equivalent Access. This feature must be built in from the ground
up. It is not an "after market" add-on. Significant investments
have been made to ensure that the .org registry supports equivalent access
for all registrars. The technical approach to ensuring equivalent access is
outlined in Section C17.10.
Recent history has clearly demonstrated that registry databases must be
designed to stand up under significant transaction volumes during peak periods.
Many new registries have experienced massive transaction volumes during their
initial start-up periods as registrars compete to be the first to grab desirable
registrations. There is, however, another significant event that most new
registries have not yet experienced and that has proven to generate massive
transaction volumes. The event is the return of desirable registrations back
into the market, an event that the current .org registry handles without
incident every day.
Database Size and Throughput
The proposed .org registry database is designed and tested to host a minimum of
100 million registrations while maintaining strict SLAs and providing robust
business continuity capabilities. It has a proven history of handling more than
100,000 transactions per minute on a continuous basis for days on end, with
peaks of more than 300,000 per minute and more than 4 billion per month. Despite
this transaction volume, the current .org registry consistently exceeds
established SLAs, processing CHECK commands in an average of under 10
milliseconds and ADD commands in under 100 milliseconds. Figure C17.3-1 is a
snapshot of these transaction volumes from the web-based monitoring tool.
Figure C17.3-1: One Hour Snapshot of Database Transaction Volumes
Transaction volume, however, is only one element required of a registry
database. Another is reliability. A registry cannot permit the loss of even a
single transaction. Therefore, multiple copies of the database must be
replicated and stored in different locations, as displayed in Figure C17.3-2. To
accomplish this, the .org registry uses data storage technology by EMC. The .org
registry database is replicated within the primary data center facility in
addition to being replicated to a geographically diverse site. Multiple copies
of the database significantly reduce the possibility of data loss or corruption,
as well as providing for speedy recovery of services in the event of a disaster.
Always having a current copy of the data means that time need not be spent
restoring from a back-up tape and replaying transaction logs in order to fully
restore the database. Of course, tape back-ups and transaction logs will be
generated and kept in the unlikely event that they will be needed, but there is
no substitute for having multiple real-time updated copies of the database.
Figure C17.3-2: Registry Database Real-Time Redundancy
The ability to handle large transaction volumes is of little use if the
system is continually subject to unscheduled and unplanned outages. In 2001, the
current .org registry operated at 99.987% reliability (refer to C17.3-3).
Figure 17.3-3: Registry Availability in 2001
Thus far, in 2002, the current .org registry is operating at 99.994%
reliability (refer to Figure C17.3-4).
Figure 17.3-4: Registry Availability in 2002
A Registry Command Center (RCC) monitors the performance of, and registrar
connectivity to, the .org database in 60-second increments. Equivalent access is
ensured through the use of multiple connection pools that guarantee each
registrar sufficient connections to enable customers with live Internet
presences to update their data, while also supporting customers who cater to the
speculation industry. Refer to Figure C17.3-5 for detail.
Figure 17.3-5: Registry Connection Pools
Using multiple pools, the .org registry is able to guarantee each registrar a
minimum number of connections (15) in the Guarantee Pool. Registrars that need
additional connections may obtain them from the Overflow Pool. The Automated
Pool is a pool of connections specifically set aside to support registrars that
exercise intensive batch processes to search for and obtain registrations as
they are deleted. Experience has demonstrated that any registry subject to a
land rush for deleted registrations must provide a mechanism by which this
activity can be performed without impacting users who are attempting to maintain
their web presence. These capabilities are discussed in detail in Section
C20.
Access to the .org database is currently accomplished through a secure RRP
connection, and database objects are created as a result of business rules in
the application servers generated from specific RRP commands received from the
registrars. The RRP protocol was designed with an attribute called "idempotency",
which permits commands to be issued multiple times but executed only once. With
the transition to EPP (discussed in detail in Section C22), registrars will be
able to use the same protocol as many of the newer registries, and the new .org
registry will be better able to extend service offerings.
The proposed .org registry will continue the current detailed level of
reporting provided to the registrars, including reports issued daily to each
individual registrar containing information such as:
- Registration activity (e.g., ADDs, DELETEs, etc.)
- Transfer activity
- Available credit
To maintain the performance and reliability of the .org database, older data
(more than three months) will be routinely migrated to the Critical Data Archive
(CDA), where it will be maintained indefinitely. In this way, data needed to
support registrar and law enforcement inquiries and/or disputes is always
available.
In the current .org database, grace periods are configurable. UIA believes
that changes to the current grace period implementations are desirable and would
cooperate fully with ICANN and the Internet community with regard to proposed
changes. Specifically, UIA would like to see a longer DELETE grace period that
would reduce the risk of registrants accidentally losing their registrations or
having them held hostage by cyber-squatters. The current ADD grace periods are
more attractive to speculators than to non-profits, and should probably be
reduced or eliminated.
Domain transfers are currently a source of significant debate among the
registrars and within the Internet community. UIA is committed to the stability
of the .org domain and believes that unbridled transfers can create problems for
registrants, just as it has in the long-distance telephony environment. UIA is,
however, also committed to working with ICANN and the constituency groups to
develop and implement transfer procedures that protect the interests of the
registrants and the stability of the .org domain. All changes to the .org
database will be performed via the RRP commands processed through the Gateway
and Applications servers, and will be maintained in database logs, making it
easy to track the historical activities of individual registrars as well as the
history of specific domain registrations. Tracking is particularly important for
financial transactions. If specific one-time data fixes are required, they will
be engineered, tested and implemented with the utmost rigor and caution, and
always with an audit trail. In the event of the default, acquisition, or closure
of a registrar, the proposed .org database has the ability to transfer domain
registrations to another registrar, either en masse or according to a specific
list of domain registrations.