Home > Blogs > Virtualize Business Critical Applications > Monthly Archives: April 2016

Monthly Archives: April 2016

vRealize Automation 7 converged blueprints

vRealize Automation 7 feature a new Blueprint format. A converged blueprint can have one to many components including:

  • Machines : vCenter, vCloud Air, vCloud Director, Amazon, KVM, Openstack, Citrix Xen, HyperV, SCVMM
  • Network & Security: Security Group, Load balancer, NAT, Routed networks.
  • Software (Install, configure, start, uninstall) : Scripts to setup the OS or to install and configure applications
  • XaaS : Workflows (I.E virtual machine customization, guest operations)

Combining these allow designing complex applications.

For example using the vRealize Automation design canvas you can put together a multiple instance machine to deploy cluster nodes with an XaaS components to create shared disks and software components to install and configure the Operating System, and application layers.

vRAblueprintClustered application in vRealize Automation 7 design canvas

Continue reading

Top Ten things to consider when moving Business Critical Applications (BCA) to the Cloud (Part 3 of 3)

In the first part we looked at public, private and Hybrid Cloud and their characteristics. In this part we will look at the common characteristics of business critical applications. In the second part , we looked at how some of these characteristics relate to the different types of Cloud infrastructure. In this final part we will look at he lifecycle of a business critical application in the cloud and the conclusion. Continue reading

Demo – Dynamically Enforcing Security on a Hot Cloned SQL Server with VMware NSX

VMware NSX is a software defined solution that brings the power of virtualization to network and security.VMware NSX

There are many great papers about NSX in general: for example here & here and many others, the purpose of this demo is not to dive into everything that NSX does, Instead I have focused on one capability in particular and that is the intelligent grouping of NSX Service Composer with the Distributed Firewall (DFW) and how to utilize it to make life easier for SQL DBAs and security admins, its doesn’t have to be only SQL Server, it can be any other database or application for that matter but for this demo I am focusing on SQL Server.

First, a bit of background: The NSX Service Composer allows us to create groups called “Security groups”. These Security groups can have a dynamic membership criteria that can be based on multiple factors: It can be part of the computer name of a VM, its guest OS name, the VM name, AD membership or a tag (tags are especially cool as they can be set automatically by 3rd party tools like antivirus and IPSs, but that is for a different demo)

These Security groups are than placed inside the Distributed Firewall (DFW) rules which allows us to manage thousands of entities with just a few rules and without the need to add these entities to the Security Group manually.

In the demo I have created an environment that is set with 0 trust policy, that means that everything is secured and every packet between the VMs is inspected, the inspection is done on the VMs vNIC level in an east-west micro segmentation way. That means that if a certain traffic is not defined in the DFW it is not allowed to go through.

This is something that wasn’t really possible to do before NSX

Our production app database is an SQL database and in the demo the DBA wants to hot-clone it aside for testing purposes, but obviously the cloned SQL Server needs to have some network traffic allowed to pass to it, yet it needs to be secured from everything else.

Instead of having the traditional testing FW zone with its own physical servers, I created the rules that apply to a test DBs in the DFW, created a dynamic membership Security Group, and nested that group in the rules. Now, any database server that I will clone which corresponds to the criteria will be automatically placed in the rules.  What’s really nice about this is that no traffic is going northbound to the perimeter FW because the packet inspection is done on the vNIC of the VMs (and only relevant rules to it are set on it) , no additional calls to security admins to configure the FW are needed after the first configuration has been made. This is a huge time saver , much more efficient in terms of resources (physical servers are now shared between zones) and a much more secure environment than having only a perimeter FW.

As usual any comment or feedback is welcome

Cheers,

Niran

 

Top Ten things to consider when moving Business Critical Applications (BCA) to the Cloud (Part 2 of 3)

In the first part we looked at public, private and Hybrid Cloud and their characteristics. In this part we will look at the common characteristics of business critical applications. We will also look at how some of these characteristics relate to the different types of Cloud infrastructure.

Common Characteristics of Business Critical Applications (BCA):

Business critical applications typically have very stringent SLAs and have a direct impact on the business. These are the crown jewels of the business that need to be managed with utmost care to avoid loss of productivity, data and potential revenue. These are the major factors can have a direct impact on these applications such as the following:

Continue reading