Session on disaster recovery

1. Disaster Recover
April 2011

2. About Orcon
…first and foremost, an Internet Service Provider
 Over 50 thousand broadband connections, with our own access network
 Over 100 thousand total internet and voice customers
 Several thousand business customers, including:
 Datacenter services
 Metro Ethernet
 Voice (SIP)
 International data
 Hosting

3. About Orcon
Some technical detail:
 Our own voice and broadband access network – 60 exchanges in 8 cities
 POPs in 13 New Zealand locations
 2 datacenters – Auckland and Wellington
 Large international presence – sites in Australia and the United States
 Lots of network capacity!
 10Gb international network AKL-SYD-LOS
 Multiple Gb nationally
 Multiple 10Gb metro AKL

4. About Orcon
Some technical detail:
 Our own voice and broadband access network – 60 exchanges in 8 cities
 POPs in 13 New Zealand locations
 2 datacenters – Auckland and Wellington
 Large international presence – sites in Australia and the United States
 Lots of network capacity!
 10Gb international network AKL-SYD-LOS
 Multiple Gb nationally
 Multiple 10Gb wavelengths metro AKL

5. About Orcon
International network
Image credit: San Diego History Centre
http://www.sandiegohistory.org/education/light8/index.htm

6. About Orcon
New Zealand network
Image credit: Enchanted Learning
http://www.enchantedlearning.com/oceania/newzealand/outlinemap/

7. About Orcon
Applications and data...
 Most applications developed internally
 BSS (billing
 OSS (provisioning)
 “Other”
 Housed in our own datacenters in Auckland and Wellington
 Lots of data
 Financial and accounting (billing, GL, debtors, etc.)
 Business data (products, services, processes, IP, etc.)
 Customer-centric data (CDRs, usage logs, personal data)
 Customer-owned data (email, websites, databases, etc.)

8. Data and Applications
Example application - Cosmos

9. Design to Fail
…using Cosmos as our example application:
 Multiple application frontends
 GSLB system in front of it
 Load balance sessions to different frontends
 Any can fail – sessions will be dropped, can log into another instance
 Replicated database behind it

10. Design to Fail
Other ideas we’ve had
 cloud-based frontends
 cloud-based databases?
 challenges – local performance, soveregncy, service levels, security, isolation
 room for local cloud?
These may or may not turn into products that we sell to others as well 

11. Design to Fail
Example – Christchurch
Scenario – Christchurch, but in Auckland
Scenario – Japan, but affecting western seaboard of US
Scenario – fire, malicious intent, network outage, loss of hardware/data loss

12. Wrapup
Design to fail, or expect failure
Consider global events
Consider global or regional coverage
Consider local presence