Author: admin

Disaster recovery isn’t just about worst-case scenarios, it’s about delivering high-availability to your core applications.

by admin

Disaster recovery (DR) is a difficult concept in IT. It requires one to not only think about the many implications of a worst-case scenario but also develop a sound response. You have to think about that crazy thing that may or may not actually happen while deciding how much resources should be committed to that theoretical event – without materially disrupting your business, of course. But what if your DR site served an additional purpose? What if you could make your DR site more than just an expensive store of data that may or may not save your behind in the event of a worst-case scenario? Well, in the modern data center it’s much easier to make your plan B your plan A.

Think about how you’ve traditionally thought about DR. It’s been “backup the heck out of our data and get it to some off-site place so we can restore it if we need to.” The obvious questions becomes, how does that backup data end up becoming a live application environment? How long will it take to transfer the backup data to new hardware? For that matter, what infrastructure are we really planning to restore to that’s geographically diverse from our production environment? At the core of these questions is data availability; and availability is really what DR is all about.

So many of today’s applications are web-based and may even include native mobile and tablet components associated with them. As an infrastructure professional in charge of the availability of these applications, redundancy, load balancing, and replication are all things you’ve probably implemented in some form. If one of the application servers goes down, it fails over to another node. Well, you know what? This is how your DR site should work too.

At Layeredi we approach DR from the standpoint of making your plan B your plan A. What that means is that to be truly resilient to a prolonged outage and achieve speedy recovery time objectives, your DR site should be a literal extension of your production environment. And this sort of setup doesn’t have to be cost prohibitive. Capacity, hardware specs and recovery time objectives can be tweaked to reflect financial constraints. Here are a few things that our team does to make DR a core application availability strategy, not only for us, but also for our customers:

Store backups in native hypervisor format

In a modern data center you’re probably highly virtualized. You may not be 100% there, but chances are your virtualization footprint is over 60%. Whether you’re running VMware or Hyper-V there are built-in tools for snapshots and other ways to quickly and easily migrate VMs from host to host.

Use VM replication

We use tools that allow us to replicate live VMs at our productions sites to powered-down VMs at our DR site. The DR VMs aren’t actually consuming resources when they’re powered down yet they can still be quickly powered on in the event of a disaster scenario. This produces a cost effective scenario whereby a replica of the production environment can be turned on in short order.

Pre-stage VM recovery

In many application environments, there are certain dependencies that need to be in place for it to be fully operational. So certain VMs need to go live before others. An example would be a Domain Controller needing to be up before you can bring on your sql server. We use tools that allow us to pre-stage the order of recovery in our DR site. When we say “recovery”, we really mean the order in which powered down replica VMs get turned on, so this process is quick.

Tiered Storage

In our production and DR environments we use flash-optimized tiered storage. What this means is that for any workload we can define whether it’s running on SSD or 7k spinning disks based on profile. This allows us to save money by keeping VMs on cheap 7k storage until they need to become production and we can instantly provide 10’s of thousands of IOPS to our applications by moving them into the SSD tier.

This was a quick primer on how we do DR for ourselves and our customers. Technology is so incredibly business-critical today, that we feel like it’s important that we continue to iterate and innovate on DR and application availability because it’s more important than ever.


Are you encrypting your data-in-flight? If not, you should be.

by admin

We spend a lot of time working with our customers to align their technology platform choices with best-practices security and compliance standards.

Over the past couple of years there has been a rash of high-profile data breaches and hack’s that have rocked the business world. At the same time there’s also been a veritable cambrian explosion of application frameworks, libraries, languages and database engines that are part of a new era of cloud-native applications – a direct response to mobile solidifying itself as the platform of the internet. ¬†With existential security risks for technology at an all-time high, and powerful cloud-native services popping up at a torrid pace, data security has never been more critical than it is today.

Having a fundamental knowledge of basic application environment security should be required for all of the members of your team. Whether dev or ops, everyone should understand the what it takes to keep your data protected. We thought it would be valuable to do a blog series of quick tips for securing your server environments and processes. Let’s start with a security fundamental that it is a requirement for nearly all of the main compliance standards: in-flight encryption.
All data that goes over your internal network or the internet is potentially vulnerable. Encrypting data in-flight means that you encrypt data when it’s being transmitted over a network.

Here are some tips to ensuring all of your data transmissions are encrypted in-flight:

  1. Don't use ftp for file transfer, it's unencrypted and insecure. Instead, use scp or sftp. Additionally, you can use rsync over ssh for secure transfer using rsync's robust feature-set. On Windows you can transfer files over Remote Desktop which is also encrypted.
  2. On your web servers, whether you're running on Windows or Linux, be sure to use TLS (transport layer security) for https on all of your connections.
  3. From time to time, a VPN is necessary to provide private, encrypted access to your network. We use OpenVPN as well as a hardware-based solution through our firewall. OpenVPN is software based, easy-to-use and is a great tool in your ops toolbox.
  4. 4. When implementing encryption, try to avoid self-signed certificates wherever possible. It's better to use a certificate that's signed by a Certificate Authority and so your public key is always verified by a trusted third party.

These 4 tips are just the basics to encrypting your data in-flight. One challenge to implementing encryption is to ensure that it's consistently implemented correctly across your entire environment as you grow. In our own infrastructure we've built encryption in-flight into our entire environment through our automation tools and we do quarterly audits of internal and customer environments. Security is a process that has to be taken seriously.

Next time we'll touch on encryption at-rest and how to secure the data you're actually storing.