GreenTree Hosting · Interactive Multi-Region Cloud, DNS & Mail Architecture Simulator

GreenTree Hosting Multi-Region Cloud, DNS & Mail Architecture — Plain-Text Summary & Oct 25, 2026 Drill Report

This summary provides the complete architectural specification, verified data center regions, and failure scenario outcomes shown in the interactive diagram.

1. Verified Data Center Footprint Across North America

GreenTree Hosting operates across three geographically separated core OVHcloud data centers (with 100% OVH hardware Edge Network Firewall coverage) and two DigitalOcean coastal regions so that compute, standby replication, object storage, managed web hosting, and authoritative DNS are never concentrated in a single facility:

Component / Node	Data Center Facility & Region	Hardware & Network Role
Cloud Node A & HTTPS Edge A (`148.113.149.8`)	OVHcloud Beauharnois, Quebec, Canada (`BHS`)	Primary Ubuntu 24.04 LTS NVMe compute node running 78 permanent Docker containers (client web applications and isolated SQL database & service containers), Primary HTTPS/TLS 1.3 Edge A, and Inbound Proxmox Mail Gateway (Round-Robin on Port 25).
Cloud Node B, HTTPS Edge B & S3 Storage (`51.81.220.192`) + `west4.greentreehosting.net` (`15.204.67.207`)	OVHcloud Hillsboro, Oregon (`US-WEST-OR` · 62.7 ms RTT from BHS)	Full-capacity Warm-Standby Ubuntu 24.04 LTS NVMe compute & storage node running Standby HTTPS/TLS 1.3 Edge B, synchronized standby application containers, writable standby PostgreSQL 16 databases (synced every 5 minutes from Cloud Node A), Inbound Proxmox Mail Gateway (Round-Robin on Port 25), SeaweedFS S3-compatible NVMe object storage, MariaDB 11.4 LTS, Cloud Mail, Customer Mail Quarantine Portal (`pmg.greentreemail.com`), and US-West web hosting (`west4`).
Inbound Mail Gateway A (Primary) & Mesh Node C (`mx.greentreemail.com` · `15.204.210.76`)	OVHcloud Virginia (`US-EAST-VA` · 14.3 ms RTT from BHS)	Primary Proxmox Mail Gateway 8.2 inbound spam, ClamAV & TLS filtering node across 106 domains (protected by OVH hardware Edge Network Firewall) and 3rd encrypted WireGuard mesh voter.
Managed Web Hosting, BIND9 Masters & SmarterMail (`east3` `15.204.224.38` · `east10` `135.148.26.170` · `ns30` `51.81.87.8` · `east.greentreemail.com` `135.148.26.49`)	OVHcloud Virginia (`US-EAST-VA` · AS16276)	Cross-mirrored BIND9 Authoritative DNS Masters A & B (187 zones), external DNS Slave #2 (`ns30.greentreedns.net`), Virtualmin managed web hosting servers (187 domains), and SmarterMail Enterprise mailbox server.
External Authoritative DNS Slaves #1 & #3 (`ns20.greentreedns.com` `161.35.230.191` · `ns40.greentreehosting.net` `143.198.51.122`)	DigitalOcean New York (`NYC`) & San Francisco (`SFO3` · AS14061)	Bi-coastal external BIND9 authoritative DNS slaves on an independent cloud provider and autonomous system (AS14061) across `.com` and `.net` TLDs, receiving real-time NOTIFY/AXFR zone transfers from both `east3` and `east10`.

2. October 25, 2026 Live Reboot & Failover Drill Report (Scenario C — Live Drill Verified)

Only scenarios that have been physically executed on production hardware carry the Live Drill Verified badge. On October 25, 2026, we ran a planned failover and full hardware reboot drill on Cloud Node A (148.113.149.8 · Beauharnois, QC):

Pre-Reboot DNS Cutover (Planned Test): Because this was a planned drill, authoritative DNS records were switched to our warm-standby compute node ahead of the reboot so warm-standby containers and writable PostgreSQL 16 databases served live traffic during the host restart (subsequently consolidated onto our Cloud Node B in Hillsboro, Oregon 51.81.220.192 so every node sits inside an OVH-owned core datacenter with hardware Edge Network Firewall protection).
Measured Container Recovery Time (78 Permanent Containers in 21 Seconds): Cloud Node A executed a full Linux kernel and hardware reboot. All 78 permanent containers (52 client web application containers and 26 isolated PostgreSQL database and service containers) came back up automatically in 21 seconds.
Legacy TTL Finding & Fix (~15–18s Interruption on Two Sites): During the reboot window, two sites (greentreehosting.com and cfelectricalservice.com) experienced an ~15–18 second interruption on recursive resolvers that were still caching their old 10.6-hour (38,400-second) DNS TTL. Running the live drill exposed that legacy TTL setting, which was immediately corrected to a 60-second TTL across all high-availability zones afterward.
Scope Note: Inbound Mail Gateways were not part of the October 25 compute reboot test.

3. Summary of All 7 Interactive Failure Scenarios

Scenario A — Authoritative DNS Master B (east10 · Virginia) Outage (Modeled · Not Yet Drilled): If east10 (135.148.26.170) stops responding, all 187 DNS zones across both the Cloud Stack and the Web Hosting / Mail Stack remain live on Master A (east3) and all three external slaves (ns20 on DigitalOcean NYC, ns30 on OVHcloud Virginia, and ns40 on DigitalOcean SFO) with zero DNS query loss.
Scenario B — Primary HTTPS Edge A (Beauharnois, Canada) Outage (Modeled · Not Yet Drilled): If the reverse proxy on Cloud Node A stops answering on Port 443, external health probes and our Off-Network Cloud Canary on Google Cloud (AS15169) alert operators. Standby HTTPS Edge B in Hillsboro, Oregon (US-WEST-OR) holds pre-synced TLS certificates and routes (synced every 5 minutes) and serves traffic when DNS switches (60s TTL).
Scenario C — Cloud Node A (Beauharnois, Canada) Planned Reboot Drill (Live Drill Verified · Oct 25, 2026): Reflects our October 25, 2026 live test: DNS was moved to our warm-standby node ahead of the reboot, Cloud Node A rebooted and restored all 78 permanent containers automatically in 21 seconds, and two sites with a legacy 10.6-hour TTL saw a brief ~15–18s interruption that led to our 60-second TTL standardization.
Scenario D — Inbound Mail Gateway A (Primary · Virginia) Outage (Modeled · Not Yet Drilled): If Primary Inbound Mail Gateway A (mx.greentreemail.com in Virginia) stops accepting Port 25 connections, external sending mail servers automatically retry the backup MX route (Inbound Mail Gateway B Standby on Cloud Node A in Beauharnois, Canada) per standard SMTP retry behavior. As a result, inbound email is briefly delayed during retry rather than lost, then delivered to SmarterMail Enterprise (east.greentreemail.com).
Scenario E — Beauharnois (BHS Canada) Utility Power Cut (Modeled · Not Yet Drilled): Each OVHcloud region operates on its own regional power chain: (1) OVHcloud Beauharnois, QC, (2) OVHcloud Virginia (US-East), and (3) OVHcloud Hillsboro, Oregon (US-West). A utility mains drop in Beauharnois engages OVHcloud's BHS facility UPS and diesel generators without affecting Virginia or Oregon.
Scenario F — Cross-Site Replication Tunnel A Reset (Modeled · Not Yet Drilled): If the encrypted WireGuard tunnel on Cloud Node A resets while Cloud Node A itself is healthy, websites on Cloud Node A stay up and continue serving visitors directly on its public IP. Mesh quorum drops from 3/3 to 2/3 (Hillsboro, Oregon and Virginia remain peered), and 5-minute cross-site database/TLS synchronization pauses and catches up automatically when the tunnel reconnects.
Scenario G — Cloud Node B (Hillsboro, Oregon US-West) Outage (Modeled · Not Yet Drilled): If Cloud Node B in Oregon goes offline, the mesh maintains 2/3 quorum between Cloud Node A (Canada) and Mail Gateway Node C (Virginia), all production client web applications and SmarterMail Enterprise continue running normally, and all S3/SQL snapshots remain preserved in our off-provider backup copy.