You are viewing an old version of this page. View the current version.
Compare with Current View Page History
« Previous Version 96 Next »
This is the set of steps we will use to migrate to the new subnet at Carinet, the shared firewall with new IP addresses.
notify DBI "replication down"
Obtain, confirm local DB backup
stop DB replication to SD PROD DB
halt all SD servers (in order web, geo, db)
sbin/shutdown -h now on web server
stop web service on web server
sudo dtomcat5 stop -force on geo
Carinet will provision the new IPs on the new sub-net
sbin/shutdown -h now on geo server
/usr/pgsql-9.0/bin/pg_ctl -D /data/9.0/data -m stop on db server
sbin/shutdown -h now on db server
SF will give the go-ahead to Carinet to proceed
CARI.net will ensure STD-ESXI/E3_1230-04-QCE server is shutdown and will transport hardware to proper chassis in order to fit the rack in C2 datacenter.
Once in C2 datacenter, CARI.net will re-ip server from 209.126.178.66 to NAT 10.224.211.12/66.240.211.12
Using the new IP, SF will connect to the STD-ESXI/E3_1230-04-QCE server as the ESXI host via the VSphere Client
Once connected, SF will power on the VMs in sequence: VCenter VM VCenter17870, Prod-DB, Prod-Geo, and Prod-Web
SF will then assign the new assigned IPs on the 10.224.211.x subnet to each of the 4 VMs, and make additional necessary configuration changes within the the VMs.
SF will then test VPN connectivity to the VMs using SSH Putty sessions.
confirm services db, geo, web
test SD application (read only)
resynch db replication
test SF application (confirm replication)
SD PROD WEB into standby
If connectivity is successful, then we are done; if not, then SF and Carinet will work together to ensure the VPN tunnel is working correctly on the new shared firewall.
decommission existing carinet firewall (carinet)
decommission additional storage server STD-CUSTOM/NEHALEM_EN_3440-04-QCE (sfgovstor01.aspadmin.net-209.126.178.126)
Decommission Private V-LAN
Add Comment
Add Comment