Files

Deploy to Phoenix / deploy (push) Has been cancelled

Details

docs: Ledger Live integration, contract deploy learnings, NEXT_STEPS updates

- ADD_CHAIN138_TO_LEDGER_LIVE: Ledger form done; public code review repo bis-innovations/LedgerLive; init/push commands
- CONTRACT_DEPLOYMENT_RUNBOOK: Chain 138 gas price 1 gwei, 36-addr check, TransactionMirror workaround
- CONTRACT_*: AddressMapper, MirrorManager deployed 2026-02-12; 36-address on-chain check
- NEXT_STEPS_FOR_YOU: Ledger done; steps completable now (no LAN); run-completable-tasks-from-anywhere
- MASTER_INDEX, OPERATOR_OPTIONAL, SMART_CONTRACTS_INVENTORY_SIMPLE: updates
- LEDGER_BLOCKCHAIN_INTEGRATION_COMPLETE: bis-innovations/LedgerLive reference

Co-authored-by: Cursor <cursoragent@cursor.com>

2026-02-12 15:46:57 -08:00

26 KiB

Raw Permalink Blame History

Phoenix Migration Plan: DBIS & ChainID 138 Services

System: Phoenix Core Migration Plan
Target: Migrate DBIS Core and ChainID 138 services to Phoenix architecture
Version: 1.0.0
Last Updated: 2026-01-09 Status: Active Documentation

Executive Summary

This document provides a comprehensive migration plan for migrating DBIS Core services and ChainID 138 (Besu/Blockchain) services from the legacy flat LAN architecture (192.168.11.x) to the Phoenix Core architecture on VLAN 160 (10.160.0.x).

Migration Strategy: Phased migration with zero-downtime DNS-based cutover. Legacy services remain operational during migration.

Current State Analysis
Target State Architecture
Migration Strategy
Detailed Migration Phases
VMID Allocation in Phoenix
Network Migration Plan
Data Migration Procedures
Service Dependencies Mapping
Cutover Procedures
Risk Mitigation
Rollback Procedures
Timeline Estimates

Current State Analysis

1.1 DBIS Core Services (Current)

Location: ml110 (192.168.11.10)
Network: Flat LAN (192.168.11.0/24)
Status: Fully deployed and operational

VMID	Service	IP Address	Status	Purpose
10100	dbis-postgres-primary	192.168.11.100	✅ Running	PostgreSQL Primary
10101	dbis-postgres-replica-1	192.168.11.101	✅ Running	PostgreSQL Replica
10120	dbis-redis	192.168.11.120	✅ Running	Redis Cache
10130	dbis-frontend	192.168.11.130	✅ Running	Frontend Admin Console
10150	dbis-api-primary	192.168.11.150	✅ Running	API Primary
10151	dbis-api-secondary	192.168.11.151	✅ Running	API Secondary

Service Dependencies:

API services depend on PostgreSQL
API services depend on Redis
Frontend depends on API services
All services use authentication (Keycloak - separate deployment)

Data Volume:

PostgreSQL: ~10GB (estimated)
Redis: ~1GB (estimated)
Application code: ~5GB (estimated)

1.2 ChainID 138 Services (Current)

Location: ml110 (192.168.11.10)
Network: Flat LAN (192.168.11.0/24)
Status: Fully deployed and operational

1.2.1 Besu Validators

VMID	Service	IP Address	Status	Purpose
1000-1004	besu-validator-1-5	192.168.11.100-104	✅ Running	Validator nodes (ChainID 138)

1.2.2 Besu Sentries

VMID	Service	IP Address	Status	Purpose
1500-1503	besu-sentry-1-4	192.168.11.150-153	✅ Running	Sentry nodes

1.2.3 Besu RPC Nodes

VMID	Service	IP Address	Status	Purpose
2500-2502	besu-rpc-1-3	192.168.11.250-252	✅ Running	RPC nodes (ChainID 138)

Service Dependencies:

Validators require P2P connectivity (port 30303)
RPC nodes depend on validators for blockchain state
RPC nodes exposed via Cloudflare Tunnel

Data Volume:

Blockchain data: ~50GB per validator (estimated)
RPC nodes: ~50GB per node (estimated)

1.3 RPC Translator Services (Current)

Location: r630-01 (192.168.11.11)
Network: Flat LAN (192.168.11.0/24)
Status: Fully deployed and operational

VMID	Service	IP Address	Status	Purpose
106	redis-rpc-translator	192.168.11.110	✅ Running	Redis for nonce locking
107	web3signer-rpc-translator	192.168.11.111	✅ Running	Web3Signer (v25.12.0)
108	vault-rpc-translator	192.168.11.112	✅ Running	Vault secrets management
2400-2402	thirdweb-rpc-1-3	192.168.11.240-242	✅ Running	RPC Translator instances

Service Dependencies:

RPC Translators depend on Besu RPC nodes
RPC Translators depend on Redis, Web3Signer, Vault

Data Volume:

Minimal (stateless services)

1.4 Current Architecture Limitations

Issues with Current Architecture:

Flat LAN: All services on single network (192.168.11.0/24)
No Network Segmentation: Limited isolation between services
VMID Conflicts: Legacy services (7800-series) conflict with planned Phoenix deployment
Single Host Dependency: All DBIS services on ml110
No VLAN-based Routing: Cannot leverage role-based NAT pools
Limited Scalability: Hard to add new services without conflicts

Target State Architecture

2.1 Phoenix Core Architecture

Network: VLAN 160 (10.160.0.0/22)
Gateway: 10.160.0.1
VMID Range: 8600-8699 (Phoenix Core)

Phoenix Core Components (Phase 0 - Already Deployed):

VMID 8600: Phoenix API (10.160.0.10)
VMID 8601: Phoenix Portal (10.160.0.11)
VMID 8602: Phoenix Keycloak (10.160.0.12)
VMID 8603: Phoenix PostgreSQL (10.160.0.13)

2.2 Target Architecture Benefits

Benefits of Phoenix Architecture:

Network Segmentation: VLAN-based isolation
Scalability: VMID range 8600-8699 supports 100 containers
Role-Based NAT: Egress NAT via Block #5 (when assigned)
Zero-Downtime Migration: DNS-based cutover
Clean Separation: No conflicts with legacy services
Future-Proof: Foundation for additional services

Migration Strategy

3.1 Migration Principles

Zero-Downtime: DNS-based cutover, no service interruption
Phased Approach: Migrate services incrementally
Parallel Operation: Legacy and Phoenix services run simultaneously
Reversible: Rollback via DNS changes
Validated: Each phase must pass validation gates before proceeding

3.2 Migration Phases Overview

Phase	Services	VMID Range	Target Network	Status
Phase 0	Phoenix Core	8600-8603	VLAN 160	✅ Complete
Phase 1	DBIS Core Services	8610-8615	VLAN 160	⏳ Planned
Phase 2	RPC Translator Services	8620-8625	VLAN 160	⏳ Planned
Phase 3	Besu Services (Validators)	8630-8639	VLAN 110 (planned)	⏳ Planned
Phase 4	Besu Services (RPC)	8640-8649	VLAN 112 (planned)	⏳ Planned
Phase 5	Legacy Cleanup	N/A	N/A	⏳ Planned

Note: Besu services migration may require separate VLANs (110, 112) per network architecture. This migration plan focuses on DBIS Core and RPC Translator services initially.

Detailed Migration Phases

Phase 1: DBIS Core Services Migration

Target: Migrate DBIS Core services (VMIDs 10100-10151) to Phoenix architecture

Phase 1.1: Pre-Migration Preparation

Prerequisites:

Phoenix Core (Phase 0) deployed and validated
Network connectivity verified (VLAN 160)
Storage capacity verified (thin1 on r630-01)
Backup procedures tested
Migration scripts prepared

Pre-Migration Tasks:

Verify Current State:

# Verify all DBIS services are running
for vmid in 10100 10101 10120 10130 10150 10151; do
    ssh root@192.168.11.10 "pct status $vmid"
done

# Verify database backups
ssh root@192.168.11.10 "pct exec 10100 -- pg_dumpall > /tmp/dbis_backup_pre_migration.sql"

Allocate VMIDs in Phoenix:

VMID 8610: DBIS PostgreSQL Primary (10.160.0.20)
VMID 8611: DBIS PostgreSQL Replica (10.160.0.21)
VMID 8612: DBIS Redis (10.160.0.22)
VMID 8613: DBIS Frontend (10.160.0.23)
VMID 8614: DBIS API Primary (10.160.0.24)
VMID 8615: DBIS API Secondary (10.160.0.25)

Phase 1.2: Database Migration (PostgreSQL)

Migration Steps:

Deploy PostgreSQL Containers:

# Create PostgreSQL Primary container (8610)
ssh root@192.168.11.11 "pct create 8610 \
    local:vztmpl/ubuntu-22.04-standard_22.04-1_amd64.tar.zst \
    --storage thin1 \
    --hostname dbis-postgres-primary-phoenix \
    --memory 4096 \
    --cores 4 \
    --rootfs thin1:100 \
    --net0 bridge=vmbr0,name=eth0,ip=10.160.0.20/22,gw=10.160.0.1,type=veth \
    --unprivileged 1 \
    --onboot 1"

# Create PostgreSQL Replica container (8611)
ssh root@192.168.11.11 "pct create 8611 \
    local:vztmpl/ubuntu-22.04-standard_22.04-1_amd64.tar.zst \
    --storage thin1 \
    --hostname dbis-postgres-replica-phoenix \
    --memory 4096 \
    --cores 4 \
    --rootfs thin1:100 \
    --net0 bridge=vmbr0,name=eth0,ip=10.160.0.21/22,gw=10.160.0.1,type=veth \
    --unprivileged 1 \
    --onboot 1"

Install and Configure PostgreSQL:

# Install PostgreSQL on primary (8610)
# (Follow PostgreSQL setup procedure from Phoenix deployment runbook)

# Restore database backup
ssh root@192.168.11.11 "pct push 8610 /tmp/dbis_backup_pre_migration.sql /tmp/"
ssh root@192.168.11.11 "pct exec 8610 -- psql -U postgres < /tmp/dbis_backup_pre_migration.sql"

# Configure replication (if replica is required)

Verify Database:

# Test connection
ssh root@192.168.11.11 "pct exec 8610 -- psql -U dbis -d dbis_core -c 'SELECT COUNT(*) FROM information_schema.tables;'"

Phase 1.3: Redis Migration

Migration Steps:

Deploy Redis Container:

# Create Redis container (8612)
ssh root@192.168.11.11 "pct create 8612 \
    local:vztmpl/ubuntu-22.04-standard_22.04-1_amd64.tar.zst \
    --storage thin1 \
    --hostname dbis-redis-phoenix \
    --memory 2048 \
    --cores 2 \
    --rootfs thin1:20 \
    --net0 bridge=vmbr0,name=eth0,ip=10.160.0.22/22,gw=10.160.0.1,type=veth \
    --unprivileged 1 \
    --onboot 1"

Install and Configure Redis:

# Install Redis
ssh root@192.168.11.11 "pct exec 8612 -- bash -c 'apt-get update && apt-get install -y redis-server'"

# Configure Redis
ssh root@192.168.11.11 "pct exec 8612 -- systemctl enable redis-server"
ssh root@192.168.11.11 "pct exec 8612 -- systemctl start redis-server"

Migrate Redis Data (if persistent data exists):

# Export data from old Redis
ssh root@192.168.11.10 "pct exec 10120 -- redis-cli --rdb /tmp/redis_backup.rdb"

# Import data to new Redis
ssh root@192.168.11.11 "pct push 8612 /tmp/redis_backup.rdb /tmp/"
ssh root@192.168.11.11 "pct exec 8612 -- redis-cli --rdb /tmp/redis_backup.rdb"

Phase 1.4: API Services Migration

Migration Steps:

Deploy API Containers:

# Create API Primary container (8614)
ssh root@192.168.11.11 "pct create 8614 \
    local:vztmpl/ubuntu-22.04-standard_22.04-1_amd64.tar.zst \
    --storage thin1 \
    --hostname dbis-api-primary-phoenix \
    --memory 4096 \
    --cores 4 \
    --rootfs thin1:50 \
    --net0 bridge=vmbr0,name=eth0,ip=10.160.0.24/22,gw=10.160.0.1,type=veth \
    --unprivileged 1 \
    --onboot 1"

# Create API Secondary container (8615)
ssh root@192.168.11.11 "pct create 8615 \
    local:vztmpl/ubuntu-22.04-standard_22.04-1_amd64.tar.zst \
    --storage thin1 \
    --hostname dbis-api-secondary-phoenix \
    --memory 4096 \
    --cores 4 \
    --rootfs thin1:50 \
    --net0 bridge=vmbr0,name=eth0,ip=10.160.0.25/22,gw=10.160.0.1,type=veth \
    --unprivileged 1 \
    --onboot 1"

Install Node.js and Deploy Application:

# Install Node.js 18 (similar to Phoenix API deployment)
# Copy application code
# Install dependencies
# Configure environment variables (point to new database and Redis)
# Run migrations
# Build application
# Create systemd service

Update Environment Variables:

Database: 10.160.0.20 (new PostgreSQL)
Redis: 10.160.0.22 (new Redis)
Keycloak: 10.160.0.12 (Phoenix Keycloak) or existing Keycloak

Phase 1.5: Frontend Migration

Migration Steps:

Deploy Frontend Container:

# Create Frontend container (8613)
ssh root@192.168.11.11 "pct create 8613 \
    local:vztmpl/ubuntu-22.04-standard_22.04-1_amd64.tar.zst \
    --storage thin1 \
    --hostname dbis-frontend-phoenix \
    --memory 2048 \
    --cores 2 \
    --rootfs thin1:30 \
    --net0 bridge=vmbr0,name=eth0,ip=10.160.0.23/22,gw=10.160.0.1,type=veth \
    --unprivileged 1 \
    --onboot 1"

Install Nginx and Deploy Frontend:

# Install Nginx
# Copy frontend build files
# Configure Nginx
# Point to new API endpoints (10.160.0.24, 10.160.0.25)

Phase 1.6: Validation and Cutover

Validation Gates:

All containers running
Database accessible and data verified
Redis accessible
API services responding to health checks
Frontend accessible
End-to-end functionality tested

Cutover Procedure:

Update DNS Records:
- dbis-admin.d-bis.org → 10.160.0.23 (new frontend)
- dbis-api.d-bis.org → 10.160.0.24 (new API primary)
- dbis-api-2.d-bis.org → 10.160.0.25 (new API secondary)
Monitor Services:
- Check logs for errors
- Monitor health endpoints
- Verify user access
Legacy Services:
- Keep legacy services running for 48 hours
- Monitor for issues
- Decommission after validation period

Phase 2: RPC Translator Services Migration

Target: Migrate RPC Translator services (VMIDs 106-108, 2400-2402) to Phoenix architecture

Phase 2.1: Pre-Migration Preparation

Prerequisites:

DBIS Core migration (Phase 1) complete (if dependencies exist)
Network connectivity verified
Storage capacity verified

VMID Allocation:

VMID 8620: Redis (10.160.0.30)
VMID 8621: Web3Signer (10.160.0.31)
VMID 8622: Vault (10.160.0.32)
VMID 8623-8625: RPC Translator instances (10.160.0.33-35)

Phase 2.2: Supporting Services Migration

Migration Steps:

Migrate Redis, Web3Signer, Vault (similar to Phase 1 patterns)
Deploy RPC Translator instances
Update configuration to point to new Besu RPC endpoints
Validate services

Phase 2.3: Cutover

Cutover Procedure:

Update DNS records
Monitor services
Decommission legacy services after validation

Phase 3: Besu Services Migration (Future)

Target: Migrate Besu services to dedicated VLANs (110, 112)

Note: Besu services migration may require:

Separate VLANs (110 for validators, 112 for RPC)
Network architecture changes
Careful coordination with blockchain operations

Status: Future phase - requires additional planning

VMID Allocation in Phoenix

4.1 VMID Allocation Table

VMID Range	Service Category	Subnet/VLAN	Purpose
8600-8603	Phoenix Core	VLAN 160 (10.160.0.0/22)	Core Phoenix services
8610-8619	DBIS Core	VLAN 160 (10.160.0.0/22)	DBIS services
8620-8629	RPC Translator	VLAN 160 (10.160.0.0/22)	RPC translation services
8630-8639	Reserved	TBD	Future use
8640-8649	Reserved	TBD	Future use
8650-8699	Reserved	VLAN 160 (10.160.0.0/22)	Future Phoenix services

4.2 IP Address Allocation

VLAN 160 Subnet: 10.160.0.0/22 (1024 addresses)

IP Range	Service	Purpose
10.160.0.10-13	Phoenix Core	Core services
10.160.0.20-29	DBIS Core	DBIS services
10.160.0.30-39	RPC Translator	RPC translation services
10.160.0.40-99	Reserved	Future services
10.160.0.100-255	Reserved	Future expansion

Network Migration Plan

5.1 Current Network (Flat LAN)

Current: All services on 192.168.11.0/24
Gateway: 192.168.11.1
Characteristics:

No network segmentation
Single broadcast domain
Limited security isolation

5.2 Target Network (VLAN-based)

Target: Services on VLAN 160 (10.160.0.0/22)
Gateway: 10.160.0.1
Characteristics:

Network segmentation
Isolated broadcast domains
Enhanced security isolation
Role-based NAT support

5.3 Migration Network Steps

Verify VLAN 160 Configuration:
- VLAN exists on switch/router
- Proxmox bridge supports VLAN tagging
- ER605 routing configured
Deploy Services on VLAN 160:
- Use static IPs in 10.160.0.0/22 range
- Configure gateway as 10.160.0.1
- Test connectivity
DNS Cutover:
- Update DNS records to point to new IPs
- Monitor services
- Verify functionality
Legacy Cleanup:
- Decommission legacy services after validation period
- Reclaim IP addresses and VMIDs

Data Migration Procedures

6.1 Database Migration

Source: PostgreSQL on 192.168.11.100 (VMID 10100)
Target: PostgreSQL on 10.160.0.20 (VMID 8610)

Procedure:

Pre-Migration Backup:

# Full database backup
ssh root@192.168.11.10 "pct exec 10100 -- pg_dump -U dbis dbis_core > /tmp/dbis_backup_$(date +%Y%m%d).sql"

# Verify backup
ssh root@192.168.11.10 "ls -lh /tmp/dbis_backup_*.sql"

Transfer Backup:

# Copy backup to new host
scp root@192.168.11.10:/tmp/dbis_backup_*.sql root@192.168.11.11:/tmp/

Restore Database:

# Restore on new database
ssh root@192.168.11.11 "pct push 8610 /tmp/dbis_backup_*.sql /tmp/"
ssh root@192.168.11.11 "pct exec 8610 -- psql -U phoenix -d phoenix < /tmp/dbis_backup_*.sql"

Verify Data:

# Compare record counts
ssh root@192.168.11.11 "pct exec 8610 -- psql -U phoenix -d phoenix -c 'SELECT COUNT(*) FROM (SELECT table_name FROM information_schema.tables WHERE table_schema='\\''public'\\'') AS tables;'"

6.2 Redis Migration

Source: Redis on 192.168.11.120 (VMID 10120)
Target: Redis on 10.160.0.22 (VMID 8612)

Procedure:

Export Redis Data (if persistent):

# Save Redis data
ssh root@192.168.11.10 "pct exec 10120 -- redis-cli SAVE"
ssh root@192.168.11.10 "pct exec 10120 -- redis-cli --rdb /tmp/redis_backup.rdb"

Import Redis Data:

# Copy to new Redis
scp root@192.168.11.10:/tmp/redis_backup.rdb root@192.168.11.11:/tmp/
ssh root@192.168.11.11 "pct push 8612 /tmp/redis_backup.rdb /tmp/"
ssh root@192.168.11.11 "pct exec 8612 -- cp /tmp/redis_backup.rdb /var/lib/redis/dump.rdb"
ssh root@192.168.11.11 "pct exec 8612 -- systemctl restart redis-server"

Note: Redis is often stateless. Migration may not require data transfer if Redis is used only for caching.

6.3 Application Code Migration

Procedure:

Copy Application Code:

# Copy API code
rsync -avz --exclude node_modules --exclude .git \
    root@192.168.11.10:/opt/dbis-core/ \
    root@192.168.11.11:/tmp/dbis-core-source/

# Copy to new container
ssh root@192.168.11.11 "pct push 8614 /tmp/dbis-core-source /opt/dbis-core --recursive"

Install Dependencies and Configure:

# Install Node.js, dependencies, configure environment
# (Follow application deployment procedures)

Service Dependencies Mapping

7.1 DBIS Core Dependencies

Internal Dependencies:

API → PostgreSQL (database queries)
API → Redis (caching)
Frontend → API (API calls)
API → Keycloak (authentication)

External Dependencies:

All services → Internet (for updates, external APIs)
Frontend → DNS (for domain resolution)

7.2 RPC Translator Dependencies

Internal Dependencies:

RPC Translator → Besu RPC (blockchain queries)
RPC Translator → Redis (nonce locking)
RPC Translator → Web3Signer (transaction signing)
RPC Translator → Vault (secrets management)

External Dependencies:

All services → Internet (for updates)

7.3 Dependency Migration Order

Recommended Migration Order:

Foundation Services First:
- PostgreSQL
- Redis
- Keycloak (if shared)
Application Services Second:
- API services
- Frontend
Supporting Services Last:
- Monitoring (if any)
- Logging (if any)

Cutover Procedures

8.1 DNS Cutover

DNS Records to Update:

Record	Current IP	New IP	Type
`dbis-admin.d-bis.org`	192.168.11.130	10.160.0.23	A
`dbis-api.d-bis.org`	192.168.11.150	10.160.0.24	A
`dbis-api-2.d-bis.org`	192.168.11.151	10.160.0.25	A

Cutover Steps:

Pre-Cutover Validation:
- All new services running and validated
- All validation gates passed
- End-to-end testing completed
Update DNS Records:

# Using Cloudflare API or dashboard
# Update each DNS record to point to new IPs

Monitor Services:
- Check logs for errors
- Monitor health endpoints
- Verify user access
- Monitor for 48 hours
Rollback (if needed):
- Revert DNS records to old IPs
- Legacy services become active again

8.2 Service Cutover

Cutover Strategy:

Parallel Operation:
- New services running alongside legacy services
- DNS cutover routes traffic to new services
- Legacy services remain running as backup
Traffic Migration:
- DNS cutover routes all traffic to new services
- Legacy services receive no traffic
- Monitor for issues
Validation Period:
- Monitor new services for 48 hours
- Verify functionality
- Check for errors
Legacy Decommission:
- After validation period, decommission legacy services
- Reclaim resources

Risk Mitigation

9.1 Identified Risks

Risk	Likelihood	Impact	Mitigation
Data loss during migration	Low	High	Multiple backups, verification procedures
Service downtime	Low	High	DNS cutover, parallel operation
Network connectivity issues	Medium	Medium	Pre-migration network validation
Application compatibility issues	Low	Medium	Pre-migration testing, validation gates
Configuration errors	Medium	Medium	Automated configuration, validation procedures

9.2 Mitigation Strategies

Data Loss Prevention:

Multiple backups before migration
Verify backups before migration
Test restore procedures
Keep legacy data for 30 days

Downtime Prevention:

DNS-based cutover (instant rollback)
Parallel operation during migration
Validation gates before cutover
Rollback procedures documented

Network Issues Prevention:

Pre-migration network validation
Test connectivity before migration
Verify firewall rules
Document network configuration

Compatibility Issues Prevention:

Pre-migration testing
Validation gates
Gradual migration (one service at a time)
Rollback procedures

Rollback Procedures

10.1 DNS Rollback

If issues are discovered after DNS cutover:

Revert DNS Records:

# Revert DNS records to old IPs
# Legacy services become active again

Investigate Issues:
- Check logs
- Identify root cause
- Fix issues
Re-attempt Migration:
- After fixing issues, re-attempt migration
- Follow migration procedures again

10.2 Service Rollback

If service-level rollback is needed:

Stop New Services:

# Stop new services (keep containers for debugging)
for vmid in 8610 8611 8612 8613 8614 8615; do
    ssh root@192.168.11.11 "pct stop $vmid"
done

Revert DNS:
- Revert DNS records to legacy IPs
- Legacy services become active
Keep New Services:
- Do not delete new containers (may contain debugging info)
- Investigate issues
- Fix and re-attempt

Timeline Estimates

11.1 Phase 1: DBIS Core Migration

Estimated Duration: 2-4 weeks

Task	Duration	Dependencies
Pre-migration preparation	2-3 days	Phoenix Core deployed
Database migration	1-2 days	Preparation complete
Redis migration	1 day	Database migration complete
API services migration	2-3 days	Database and Redis migrated
Frontend migration	1-2 days	API services migrated
Validation and testing	3-5 days	All services migrated
DNS cutover	1 day	Validation complete
Legacy decommission	1-2 days	Cutover successful

Total: 2-4 weeks (including validation period)

11.2 Phase 2: RPC Translator Migration

Estimated Duration: 1-2 weeks

Task	Duration	Dependencies
Pre-migration preparation	1-2 days	Phase 1 complete (if dependencies)
Supporting services migration	1-2 days	Preparation complete
RPC Translator migration	2-3 days	Supporting services migrated
Validation and testing	2-3 days	All services migrated
DNS cutover	1 day	Validation complete
Legacy decommission	1 day	Cutover successful

Total: 1-2 weeks

11.3 Phase 3: Besu Services Migration (Future)

Estimated Duration: TBD (requires additional planning)

Success Criteria

12.1 Migration Success Criteria

Phase 1 (DBIS Core) is successful when:

All services running on VLAN 160
All validation gates passed
DNS cutover completed
Services accessible via new IPs
No user-reported issues for 48 hours
Legacy services decommissioned
Documentation updated

Phase 2 (RPC Translator) is successful when:

All services running on VLAN 160
All validation gates passed
DNS cutover completed
Services accessible via new IPs
No user-reported issues for 48 hours
Legacy services decommissioned

Post-Migration Tasks

13.1 Immediate Post-Migration

Monitor Services:
- Check logs daily
- Monitor health endpoints
- Verify user access
Update Documentation:
- Update service documentation
- Update network diagrams
- Update runbooks
Cleanup:
- Remove legacy containers (after validation period)
- Reclaim IP addresses
- Reclaim VMIDs

13.2 Long-Term Post-Migration

Optimization:
- Optimize performance
- Optimize resource allocation
- Review and optimize configuration
Enhancement:
- Implement additional security controls
- Implement monitoring and alerting
- Implement backup and recovery procedures
Future Migration:
- Plan Phase 3 (Besu services) migration
- Plan additional service migrations
- Plan network architecture enhancements

Phoenix Deployment Runbook: docs/03-deployment/PHOENIX_DEPLOYMENT_RUNBOOK.md
Phoenix Firewall Rules: docs/04-configuration/PHOENIX_VLAN160_FIREWALL_RULES.md
Phoenix DNS Template: docs/04-configuration/PHOENIX_DNS_ZONE_TEMPLATE.md
Phoenix System Boundary: docs/02-architecture/PHOENIX_SYSTEM_BOUNDARY_STATEMENT.md
Network Architecture: docs/02-architecture/NETWORK_ARCHITECTURE.md
VMID Allocation: docs/02-architecture/VMID_ALLOCATION_FINAL.md

Last Updated: 2026-01-09
Status: Draft - Ready for Review
Next Review: Before Phase 1 execution

26 KiB Raw Permalink Blame History

Phoenix Migration Plan: DBIS & ChainID 138 Services

Executive Summary

Table of Contents

Current State Analysis

1.1 DBIS Core Services (Current)

1.2 ChainID 138 Services (Current)

1.2.1 Besu Validators

1.2.2 Besu Sentries

1.2.3 Besu RPC Nodes

1.3 RPC Translator Services (Current)

1.4 Current Architecture Limitations

Target State Architecture

2.1 Phoenix Core Architecture

2.2 Target Architecture Benefits

Migration Strategy

3.1 Migration Principles

3.2 Migration Phases Overview

Detailed Migration Phases

Phase 1: DBIS Core Services Migration

Phase 1.1: Pre-Migration Preparation

Phase 1.2: Database Migration (PostgreSQL)

Phase 1.3: Redis Migration

Phase 1.4: API Services Migration

Phase 1.5: Frontend Migration

Phase 1.6: Validation and Cutover

Phase 2: RPC Translator Services Migration

Phase 2.1: Pre-Migration Preparation

Phase 2.2: Supporting Services Migration

Phase 2.3: Cutover

Phase 3: Besu Services Migration (Future)

VMID Allocation in Phoenix

4.1 VMID Allocation Table

4.2 IP Address Allocation

Network Migration Plan

5.1 Current Network (Flat LAN)

5.2 Target Network (VLAN-based)

5.3 Migration Network Steps

Data Migration Procedures

6.1 Database Migration

6.2 Redis Migration

6.3 Application Code Migration

Service Dependencies Mapping

7.1 DBIS Core Dependencies

7.2 RPC Translator Dependencies

7.3 Dependency Migration Order

Cutover Procedures

8.1 DNS Cutover

8.2 Service Cutover

Risk Mitigation

9.1 Identified Risks

9.2 Mitigation Strategies

Rollback Procedures

10.1 DNS Rollback

10.2 Service Rollback

Timeline Estimates

11.1 Phase 1: DBIS Core Migration

11.2 Phase 2: RPC Translator Migration

11.3 Phase 3: Besu Services Migration (Future)

Success Criteria

12.1 Migration Success Criteria

Post-Migration Tasks

13.1 Immediate Post-Migration

13.2 Long-Term Post-Migration

Related Documentation

26 KiB

Raw Permalink Blame History