Subscribe to Blog via Email
When tearing down an AWS Delphix Trial, we run the following command with Terraform:
I’ve mentioned before that every time I execute this command, I suddenly feel like I’m in control of the Death Star in Star Wars:
As this runs outside of the AWS EC2 web interface, you may see some odd information in your dashboard. In our example, we’ve run “terraform destroy” and the tear down was successful:
So you may go to your volumes and after verifying that yes, no volumes exist:
The instances may still show the three instances that were created as part of the trial, (delphix engine, source and target.)
These are simply “ghosts of instances past.” The tear down was completely successful and there’s simply a delay before the instance names are removed from the dashboard. Notice that they no longer are listed with a public DNS or IP address. This is a clear indication that these aren’t currently running, exist or more importantly, being charged for.
Just one more [little] thing to be aware of… 🙂
Now, for most of us, we’re living in a mobile world, which means as our laptop travels, our office moves and our IP address changes. This can be a bit troubling for those that are working in the cloud and our configuration to our cloud relies on locating us via our IP Address being the same as it was in our previous location.
What happens if you’re IP Address changes from what you have in your configuration file, (in Terraform’s case, your terraform.tfvars file) for the Delphix AWS Trial? I set my IP Address purposefully incorrect in the file to demonstrate what would happen after I run the terraform apply command:
It’s not the most descriptive error, but that I/O timeout should tell you right away that terraform can’t connect back to your machine.
Now, we’ll tell you to capture your current IP address and update the IP address in the TFVARS file that resides in the Delphix_demo folder, but I know some of you are wondering why we didn’t just build out the product to adjust for an IP address change.
The truth is, you can set a static IP Address for your laptop OR just alias your laptop with the IP Address you wish to have. There are a number of different ways to address this, but looking into the most common, let’s dig into how we would update the IP address vs. updating the file.
You can go to System Preferences or Control Panel, (depending on which OS you’re on) and click on Network and configure your TCP/IP setting to manual and type in an IP Address there. The preference is commonly to choose a non-competitive IP address, (often the one that was dynamically set will do as your manual one to retain) and choose to save the settings. Restart the PC and you can then add that to your configuration files. Is that faster than just updating the TFVARS file- nope.
The second way to do this is to create an Alias IP address to deter from the challenge of each location/WiFi move having it automatically assigned.
Just as above, we often will use the IP address that was given dynamically and just choose to keep this as the one you’ll keep each time. If you’re unsure of what your IP is, there are a couple ways to collect this information:
Open up a browser and type in “What is my IP Address“
or from a command prompt, with “en0” being your WiFi connection, gather your IP Address one of two ways:
$ dig +short myip.opendns.com @resolver1.opendns.com
$ ipconfig getifaddr en0
Then set the IP address and cycle the your WiFi connection:
$ sudo ipconfig set en0 INFORM <IP Address> $ sudo ifconfig en0 down $ sudo ifconfig en0 up
You can also click on your WiFi icon and reset it as well. Don’t be surprised if this takes a while to reconnect. Renewing and releasing of IP addresses can take a bit across the network and the time required must be recognized.
Depending on which OS you’re on. Using the IP Address from your tfvars file, set it as an alias with the following command:
$ sudo ifconfig en0 alias <IP Address> 255.255.255.0 Password: <admin password for workstation>
If you need to unset it later on:
sudo ifconfig en0 -alias <IP Address>
I found this to be an adequate option- the alias was always there, (like any other alias, it just forwards everything onto the address that you’re recognized at in the file.) but it may add time to the build, (still gathering data to confirm this.) With this addition, I shouldn’t have to update my configuration file, (for the AWS Trial, that means setting it in our terraform.tfvars in the YOUR_IP parameter.)
The browser commands to gather your IP Address work the same way, but if you want to change it via the command line, the commands are different for Windows PC’s:
netsh interface ipv4 show config
You’ll see your IP Address in the configuration. If you want to change it, then you need to run the following:
netsh interface ipv4 set address name="Wi-Fi" static <IP Address> 255.255.255.0 <Gateway>
netsh interface ipv4 show config
You’ll see that the IP Address for your Wi-Fi has updated to the new address. If you want to set it to DHCP, (dynamic) again, run the following:
netsh interface ipv4 set address name="Wi-Fi" source=dhcp
Now you can go wherever you darn well please, set an alias and run whatever terraform commands you wish. All communication will just complete without any error due to a challenging new IP address.
Ain’t that just jiffy? OK, it may be quicker to just gather the IP address and update the tfvars file, but just in case you wanted to know what could be done and why we may not have built it into the AWS Trial, here it is! 🙂
There are more configurations for AWS than there are fish in the sea, but as the rush of folks arrive to test out the incredibly cool AWS Trial for Delphix, I’ll add my rendition of what to look for to know you’re AWS setup is prepped to successfully deploy.
After you’ve selected your location, set up your security user/group and key pairs, there’s a quick way to see, (at least high level) if you’re ready to deploy the AWS Trial to the zone in question.
Go to your EC2 Dashboard and to the location, (Zone) that you plan to deploy your trial to and you should see the following:
Notice in the dashboard, you can see that the key pairs, (1) and the expected Security Groups, (3) are displayed, which tells us that we’re ready to deploy to this zone. If we double click on the Key Pair, we’ll see that its match to the one we downloaded locally and will use in our configuration with Terraform:
These are essential to deploying in an AWS zone that’s configured as part of your .tfvars file for terraform. You’ll note in the example below, we have both designated the correct zone and the key pair that is part of the zone we’ll be using to authenticate:
#VERSION=004 #this file should be named terraform.tfvars # ENTER INPUTS BELOW access_key="XXXXXXX" secret_key="XXXXXXXXXX" aws_region="us-east-1" your_ip="xxx.xx.xxx.xxx" key_name="Delphix_east1" #don't include .pem in the key name instance_name="Delphix_AWS" community_username="email@example.com" community_password="password"
Hopefully this is a helpful first step in understanding how zones, key pairs and security groups interact to support the configuration file, (tfvars) file that we use with the Delphix deployment via Terraform into AWS.
Delphix focuses on virtualizing non-production environments, easing the pressure on DBAs, resources and budget, but there is a second use case for product that we don’t discuss nearly enough.
Protection from data loss.
Jamie Pope, one of the great guys that works in our pre-sales engineering group, sent Adam and I an article on one of those situations that makes any DBA, (or an entire business, for that matters) cringe. GitLab.com was performing some simple maintenance and someone deleted the wrong directory, removing over 300G of production data from their system. It appears they were first going to use PostgreSQL “vacuum” feature to clean up the database, but decided they had extra time to clean up some directories and that’s where it all went wrong. To complicate matters, the onsite backups had failed, so they had to go to offsite ones, (and every reader moans…)
Even this morning, you can view the tweets of the status for the database copy and feel the pain of this organization as they try to put right the simple mistake.
Users are down as they work to get the system back up. Just getting the data copied before they’re able to perform the restore is painful and as a DBA, I feel for the folks involved:
How could Delphix have saved the day for GitLab? Virtual databases, (VDBs) are read/write copies and derived from a recovered image that is compressed, duplicates removed and then kept in a state of perpetual recovery having the transactional data applied in a specific interval, (commonly once every 24 hrs) to the Delphix Engine source. We support a large number of database platforms, (Oracle, SQL Server, Sybase, SAP, etc) and are able to virtualize the applications that are connected to them, too. The interval of how often we update the Delphix Engine source is configurable, so depending on network and resources, this interval can be decreased to apply more often, depending on how up to date the VDBs need to be vs. production.
With this technology, we’ve come into a number of situations where customers suffered a cataclysmic failure situation in production. While traditionally, they would be dependent upon a full recovery from a physical backup via tape, (which might be offsite) or scrambling to even find a backup that fit within a backup to tape window, they suddenly discovered that Delphix could spin up a brand new virtual database with the last refresh before the incident from the Delphix source and then use a number of viable options to get them up and running quickly.
This is the type of situation happens more often then we’d like to admit. Many times resources have been working long shifts and make a mistake due to exhaustion, other times someone unfamiliar and with access to something they shouldn’t simply make a dire mistake, but these things happen and this is why DBAs are always requesting two or three methods of backups. We learn quite quickly we’re only as good as our last backup and if we can’t protect the data, well, we won’t have a job for very long.
Interested in testing it out for yourself? We have a really cool free Delphix trial via Amazon cloud that uses your AWS account. There’s a source host and databases, along with a virtual host and databases, so you can create VDBs, blow away tables, recovery via a VDB, create a V2P, (virtual to physical) all on your own.
I don’t want to alarm you, but there’s a new Delphix trial on AWS! It uses your own AWS account and with a simple set up, allows you to deploy a trial Delphix environment. Yes, you hear me right- just with a couple steps, you could have your own setup to work with Delphix!
There’s documentation to make it simple to deploy, simple to understand and then use cases for individuals determined by their focus, (IT Architect, Developer, Database Administrator, etc.)
This was a huge undertaking and I’m incredibly proud of Delphix to be offering this to the community!
So get out there and check this trial out! All you need is an AWS account on Amazon and if you don’t have one, it only takes a few minutes to create one and set it up, just waiting for a final verification before you can get started! If you have any questions or feedback about the trial, don’t hesitate to email me at dbakevlar at gmail.