About a week ago, I was asked as a vExpert NSX if I wanted to participate in a Exclusive Blogger Early Access Program Session about Networking and of course I couldn’t refuse this unique change to pick up blogging again.

In this article I’d like to highlight which I think are the most important new features on the this new major release of NSX-T: VMware’s Single Heterogeneous SDN (Software Defined Networking) Platform. NSX-T provides full stack networking and security virtualization.

What’s New?

NSX-T 3.0 definitely qualifies as a major release, just check out the shear amount of the new features provided by this release:

VMware tells us they think NSX-T is now even beyond feature parity when compared to NSX-V. So if you where not yet considering (migrating to) NSX-T into your enterprise environment, you should definitely look at it for the NSX-T 3.0 release.

NSX Multi-Site / Federation

A feature we are waiting for a long time is the ability to centrally manage multiple NSX-T instances running on different sites. With NSX-T 3.0 we are now able to implement a manager of managers (global manager).

This will give us the capability to consistently manage networking and security across different sites and even allows for disaster recovery scenarios. Additionaly we can now use groups which are based on tag on any dynamic information!!!

L3 Multicast routing

A major network functionality still missing from the NSX-T product, was the ability to do L3 multicast routing. NSX-T 3.0 now introduces this capability and will be able to propagate multicast joins throughout the distributed as well to pass the information to the attached physical networking via the T0-router.

Distributed IDS

In NSX-T 3.0, VMware introduces a distributed Intrusion Detection and Prevention System which has major advantages to traditional centralized IDS/IPS systems such as:

• Distributed & Built-In Analysis
  As other NSX features such as DFW, scales linearly with the workloads and has no blind-spots.
• Curated Signature Distribution
  Which leads to fewer false positivies and lower computational overhead on the host-level, because it only applies significant policies to vNic’s. So i.e. only webserver policies apply to vNic’s for Webserver machines.
• Context-based Thread Detection
  Which allows for better alert prioritization, because of the additional information which is available in which the threat did occur.
• Policy & State Mobility
  Simplifies operations and eliminates stale / redundant policies. So also this policy moves with the VM when vMotioning across your environment.
  

IDS/IPS functionality is deployed during host preparation for NSX-T 3.0, so it is very easy to deploy.

No more traffic hair-pinning traffic over firewalls with IDS/IPS or seperate IDS/IPS-appliances, but IDS/IPS integrated into your virtualized network. And what about all the additional context information from your virtual environment which you can now use to interpret alerts. Can’t wait to start testing this great new feature!

vSphere 7 on Kubernetes support

As you probably are aware VMware introduced vSphere 7 on Kubernetes (Project Pacific) recently. NSX-T 3.0 will support this new offering and provide networking and security in this environment. Will do a seperate blog article on this feature later on.

vSphere 7 Converged VDS

With the recent General Availability of vSphere 7 and the latest VDS (Virtual Distributed Switch) 7.0, which comes with the latest release. NSX-T 3.0 now supports running NSX-T 3.0 straight on this new VDS version and use existing dvPortGroups for NSX-T switching.

What is even better is that when deploying NSX on VDS 7.0 no VM traffic distruption will occur!

This feature is for greenfield customers only. Customers who upgraded to vSphere 7 from a older versions, can continue to use the N-VDS which got installed & configured with the deployment of previous NSX-T versions.

More Information

For more information on this big release please refer to following links.

Release notes:
Link

Download:
Link

Conclusion

I think with all the operational improvements and all the exciting new features, NSX-T 3.0 will be a game changer!

Can’t wait to get my hands dirty with this solutions and provide you deeper information on the new features in future blog articles and talk about other features we did not even touch upon in this article.

The post NSX-T 3.0 GA! appeared first on RobertVerdam.eu.

Ansible

For anyone unfamiliar with Ansible, I think this quote from the Ansible site covers what it is and what it does. For more information on Ansible please visit their site:

App deployment, configuration management and orchestration – all from one system. Ansible is powerful automation that you can learn quickly.

https://www.ansible.com/

Terraform Ansible Provider Plugin

As shown in the previous blog post first we will need the Terraform Ansible Provider Plugin to be able to define Ansible inventory information from within Terraform. This allows us to define groups (i.e. security for bastionhosts, db for database-servers and web for web/app-servers), which we can do to target our specific configuration needs to the different kinds of servers we have in our application infrastructure.

This Ansible Provider Plugin can be found here and needs to be installed in the plugins directory. Which in my case (Ubuntu 18.04) has to be located in ~/.terraform.d/plugins (so in the users home-directory). More information on the location of 3th-party Terraform plugins can be found here.

After deploying your application infrastructure with Terraform the Ansible Inventory information will now be stored in the Terraform state-file (terraform.tfstate) which we can then use in Ansible by using a Ansible dynamic inventory script made for reading directly from terraform state.

Terraform Dynamic Inventory Script

The Terraform Dynamic Inventory Script can now be used to retrieve the information from the state-file.

This information can now be used in a Ansible playbook and allows for targeting the specific systems in your deployment by using the group specified in the Terraform Ansible resources.

As you see above we put the database servers in the db groups and now we use this in the Ansible configuration to fully update the instance before installing MySql on the specific server.

Now we are ready to run our Ansible-playbook and further configure our application and thus putting it all together. I’ve built a short bash-script to run all the actions which are needed to deploy the application in a repeatable manner.

As mentioned in the previous blogpost, it is also very easy to destroy the application again if needed by running, which cleans up your full application infrastructure (very useful when not wanting to incur costs during blog post creation ) :
terraform destroy -var environment=DEV -var application=APP01 -auto-approve

Demo

Have a look at the full demo which shows what the execution of the deployment script looks like and the resulting infrastructure on AWS.

End of part 2 – Please stay tuned!

At a later stage, I will publish the full source code for you to be able to deploy the same kind of ‘dummy’ application. Currently, the example is just deploying a dummy application because I didn’t have the time yet to also set-up and deploy the configuration files for Apache2, MySQL and PHP to build a demo-application, but this will definitely happen in the future.

So please stay tuned for part 3 of this blogpost-series which will talk about how the application deployment developed from this stage on. If you have any specific questions at the moment about the set-up please feel to contact me.

The post Deploying an application to AWS with Terraform and Ansible – Part 2 (Ansible) appeared first on RobertVerdam.eu.

This article series shows how I used Terraform and Ansible to make this possible.

This first blog post in this series is about setting up the application infrastructure by using the Infrastructure-As-Code tooling Terraform by HashiCorp. Prior to this blog post I created a small demo which shows how the application is deployed by Terraform, after which Ansible takes over and starts the configuration of the webservers and database servers. This blog post series shows how this was built.

Terraform

For people unfamiliar with HashiCorp Terraform: Terraform allows you to define infrastructure as code (IaC) and deploy it repeatably with the same end result. The application infrastructure is defined in code by defining needed components like compute instances, storage buckets, networks, load-balancers, firewalls etc. Terraform will then take this blueprint and plan how to reach the desired state defined in the code. This also allows TerraForm to do incremental changes by comparing the defined (changed) state with the deployed (current) state and execute only the needed changes. We simply create a  file (or multiple files) with the .tf extension and defining all the components we need. In my case I chose to split the files up by the components they defined (network, compute, ansible, etc.).

Defining AWS Provider

After installing Terraform (Link), first, we start off by defining a so-called provider (in our case AWS), which will provide the needed the resources to run the application we want to deploy. Many more providers are available  which we can use to define our infrastructure (i.e. Azure Stack, Oracle Cloud Platform VMware vSphere). For a full list of Terraform providers please check out this link.

In the following piece of code, we tell in which region to deploy the resources, which credentials to use and which profile to use (which is defined by a section in the shared credentials file) and which role TerraForm should assume to deploy the defined infrastructure.

You can remove the assume_role part if the defined credentials have sufficient rights to deploy the application to account in which the application has to be deployed. The assume role allows you to deploy the application to another AWS account :

provider "aws" {
  region = "eu-west-1"
  shared_credentials_file = "~/.creds"
  profile = "DEV"
  assume_role {
    role_arn     = "arn:aws:iam::<account>:role/Terraform"
  }
}

The shared credentials file should be set up as following:

[DEV]
aws_access_key_id=<ENTER YOUR AWS ACCESS KEY HERE>
aws_secret_access_key=<ENTER YOUR AWS SECRET ACCESS KEY HERE>

Defining AWS network-components

After we have the provider defined we can continue defining the different AWS resources we need to deploy the application. We’ll start by defining the VPC and the subnets we need. 

As you can see we are also using some variables  ( i.e. ${var.environment} ) which we can use the customize the set-up during deployment. To link the subnets to the defined VPC we refer to the VPC in the definition of the subnet.

resource "aws_vpc" "robertverdam" {
  cidr_block = "10.0.0.0/16" # Defines overall VPC address space
  enable_dns_hostnames = true # Enable DNS hostnames for this VPC
  enable_dns_support = true # Enable DNS resolving support for this VPC
  tags{
      Name = "VPC-${var.environment}" # Tag VPC with name
  }
}

resource "aws_subnet" "pub-web-az-a" {
  availability_zone = "eu-west-1a" # Define AZ for subnet
  cidr_block = "10.0.11.0/24" # Define CIDR-block for subnet
  map_public_ip_on_launch = true # Map public IP to deployed instances in this VPC
  vpc_id = "${aws_vpc.robertverdam.id}" # Link Subnet to VPC
  tags {
      Name = "Subnet-EU-West-1a-Web" # Tag subnet with name
  }
}

resource "aws_subnet" "pub-web-az-b" {
    availability_zone = "eu-west-1b"
    cidr_block = "10.0.12.0/24"
    map_public_ip_on_launch = true
    vpc_id = "${aws_vpc.robertverdam.id}"
      tags {
      Name = "Subnet-EU-West-1b-Web"
  }
}

resource "aws_subnet" "priv-db-az-a" {
  availability_zone = "eu-west-1a"
  cidr_block = "10.0.1.0/24"
  map_public_ip_on_launch = false
  vpc_id = "${aws_vpc.robertverdam.id}"
  tags {
      Name = "Subnet-EU-West-1a-DB"
  }
}

resource "aws_subnet" "priv-db-az-b" {
    availability_zone = "eu-west-1b"
    cidr_block = "10.0.2.0/24"
    map_public_ip_on_launch = false
    vpc_id = "${aws_vpc.robertverdam.id}"
      tags {
      Name = "Subnet-EU-West-1b-DB"
  }
}

To be able to access the instances (which have a mapped public IP) from the internet and allows access to the internet we will need an internet gateway, so let’s define one!:

resource "aws_internet_gateway" "inetgw" {
  vpc_id = "${aws_vpc.robertverdam.id}"
  tags {
      Name = "IGW-VPC-${var.environment}-Default"
  }
}

Looks easy, right? But you may also have guessed we also will need to set-up a route-table to attach to the subnets which define the default route and allows the subnets to talk to each other

resource "aws_route_table" "eu-default" {
  vpc_id = "${aws_vpc.robertverdam.id}"

  route {
      cidr_block = "0.0.0.0/0" # Defines default route 
      gateway_id = "${aws_internet_gateway.inetgw.id}" # via IGW
  }

  tags {
      Name = "Route-Table-EU-Default"
  }
}

resource "aws_route_table_association" "eu-west-1a-public" {
  subnet_id = "${aws_subnet.pub-web-az-a.id}"
  route_table_id = "${aws_route_table.eu-default.id}"
}

resource "aws_route_table_association" "eu-west-1b-public" {
  subnet_id = "${aws_subnet.pub-web-az-b.id}"
  route_table_id = "${aws_route_table.eu-default.id}"
}


resource "aws_route_table_association" "eu-west-1a-private" {
  subnet_id = "${aws_subnet.priv-db-az-a.id}"
  route_table_id = "${aws_route_table.eu-default.id}"
}

resource "aws_route_table_association" "eu-west-1b-private" {
  subnet_id = "${aws_subnet.priv-db-az-b.id}"
  route_table_id = "${aws_route_table.eu-default.id}"
}

Define AWS Instances

Having the networking part of our Terraform definition ready we will continue on configuring the needed computing instances, for which we will define which AMI (Amazon Machine Image) to use, what instance_type (t2.micro), which tags the instance will get, which subnet it is in and which key pair to use for accessing the instance via SSH. Finally, we define which security groups will be attached to the instance (security groups act as a firewall directly attached to the virtual network interface of the instance). Of course, we have to define these security groups later on.

resource "aws_instance" "WEBA" {
    ami = "${lookup(var.aws_ubuntu_awis,var.region)}"
    instance_type = "t2.micro"
    tags {
        Name = "${var.environment}-WEB001"
        Environment = "${var.environment}"
        sshUser = "ubuntu"
    }
    subnet_id = "${aws_subnet.pub-web-az-a.id}"
    key_name = "${aws_key_pair.keypair.key_name}"
    vpc_security_group_ids = ["${aws_security_group.WebserverSG.id}"]
}
resource "aws_instance" "WEBB" {
    ami = "${lookup(var.aws_ubuntu_awis,var.region)}"
    instance_type = "t2.micro"
    tags {
        Name = "${var.environment}-WEB002"
        Environment = "${var.environment}"
        sshUser = "ubuntu"
    }
    subnet_id = "${aws_subnet.pub-web-az-b.id}"
    key_name = "${aws_key_pair.keypair.key_name}"
    vpc_security_group_ids = ["${aws_security_group.WebserverSG.id}"]
}
resource "aws_instance" "BASTIONHOSTA" {
    ami = "${lookup(var.aws_ubuntu_awis,var.region)}"
    instance_type = "t2.micro"
    tags {
        Name = "${var.environment}-BASTION001"
        Environment = "${var.environment}"
        sshUser = "ubuntu"
    }
    subnet_id = "${aws_subnet.pub-web-az-a.id}"
    key_name = "${aws_key_pair.keypair.key_name}"
    vpc_security_group_ids = ["${aws_security_group.bastionhostSG.id}"]
}

resource "aws_instance" "BASTIONHOSTB" {
    ami = "${lookup(var.aws_ubuntu_awis,var.region)}"
    instance_type = "t2.micro"
    tags {
        Name = "${var.environment}-BASTION002"
        Environment = "${var.environment}"
        sshUser = "ubuntu"
    }
    subnet_id = "${aws_subnet.pub-web-az-b.id}"
    key_name = "${aws_key_pair.keypair.key_name}"
    vpc_security_group_ids = ["${aws_security_group.bastionhostSG.id}"]
}

resource "aws_instance" "SQLA" {
    ami = "${lookup(var.aws_ubuntu_awis,var.region)}"
    instance_type = "t2.micro"
    tags {
        Name = "${var.environment}-SQL001"
        Environment = "${var.environment}"
        sshUser = "ubuntu"
    }
    subnet_id = "${aws_subnet.priv-db-az-a.id}"
    key_name = "${aws_key_pair.keypair.key_name}"
    vpc_security_group_ids = ["${aws_security_group.DBServerSG.id}"]
}

resource "aws_instance" "SQLB" {
    ami = "${lookup(var.aws_ubuntu_awis,var.region)}"
    instance_type = "t2.micro"
    tags {
        Name = "${var.environment}-SQL002"
        Environment = "${var.environment}"
        sshUser = "ubuntu"
    }
    subnet_id = "${aws_subnet.priv-db-az-b.id}"
    key_name = "${aws_key_pair.keypair.key_name}"
    vpc_security_group_ids = ["${aws_security_group.DBServerSG.id}"]
}

Defining Classic Loadbalancer

In front of the application, we will be placing a classic load balancer, which will load-balance incoming web traffic (port 80) across the availability zones (eu-west-1a & eu-west-1b) in which the web servers are located. In a later article, we will be replacing this classic load balancer with a more advanced application load balancers.

resource "aws_elb" "lb" {
    name_prefix = "${var.environment}-"
    subnets = ["${aws_subnet.pub-web-az-a.id}", "${aws_subnet.pub-web-az-b.id}"]
    health_check {
        healthy_threshold = 2
        unhealthy_threshold = 2
        timeout = 3
        target = "HTTP:80/"
        interval = 30
    }
    listener {
        instance_port = 80
        instance_protocol = "http"
        lb_port = 80
        lb_protocol = "http"
    }
    cross_zone_load_balancing = true
    instances = ["${aws_instance.WEBA.id}", "${aws_instance.WEBB.id}"]
    security_groups = ["${aws_security_group.LoadBalancerSG.id}"]
}

Defining Security Groups

As mentioned before we will be attaching security groups to the defined compute instances and also the defined load balancer to only allow the specified incoming (ingress) and specified outgoing (egress) traffic. Besides using CIDR blocks subnets, we can also define other security groups as allowed traffic.

Also, you see an example of using separate rules attached to an security group ( resource aws_security_group_rule ). This prevents Terraform running into trouble because it can’t figure out which resource to create first (circular reference between the security groups). If this happens we then simply define the separate rules which we attach to the security rules. This allows Terraform to first create the security groups without the rules and attach them later, so solving the circular reference.

Also notice that we are using the bastion-hosts as proxies for the instances in the private subnets to access the internet via a squid proxy which will be installed to the bastion-hosts by Ansible.

resource "aws_security_group" "LoadBalancerSG"
{
    name = "LoadBalancerSG"
    vpc_id = "${aws_vpc.robertverdam.id}"
    description = "Security group for load-balancers"
    ingress {
        from_port = 80
        to_port = 80
        protocol = "TCP"
        cidr_blocks = ["0.0.0.0/0"]
        description = "Allow incoming HTTP traffic from anywhere"
    }
    ingress {
        from_port = 443
        to_port = 443
        protocol = "TCP"
        cidr_blocks = ["0.0.0.0/0"]
        description = "Allow incoming HTTPS traffic from anywhere"
    }

    egress {
        from_port = 80
        to_port = 80
        protocol = "TCP"
        security_groups = ["${aws_security_group.WebserverSG.id}"]
    }

    egress {
        from_port = 443
        to_port = 443
        protocol = "TCP"
        security_groups = ["${aws_security_group.WebserverSG.id}"]
    }

    tags
    {
        Name = "SG-Loadbalancer"
    }
}
resource "aws_security_group" "WebserverSG"
{
    name = "WebserverSG"
    vpc_id = "${aws_vpc.robertverdam.id}"
    description = "Security group for webservers"
    ingress {
        from_port = 22
        to_port = 22
        protocol = "TCP"
        security_groups = ["${aws_security_group.bastionhostSG.id}"]
        description = "Allow incoming SSH traffic from Bastion Host"
    }
  ingress {
      from_port = -1
      to_port = -1
      protocol = "ICMP"
      security_groups = ["${aws_security_group.bastionhostSG.id}"]
      description = "Allow incoming ICMP from management IPs"
  }
    egress {
        from_port = 0
        to_port = 0
        protocol = "-1"
        self = true
    }
    egress {
        from_port = 3128
        to_port = 3128
        protocol = "TCP"
        security_groups = ["${aws_security_group.bastionhostSG.id}"]
    }
    tags
    {
        Name = "SG-WebServer"
    }
}

resource "aws_security_group" "bastionhostSG" {
  name = "BastionHostSG"
  vpc_id = "${aws_vpc.robertverdam.id}"
  description = "Security group for bastion hosts"
  ingress {
      from_port = 22
      to_port = 22
      protocol = "TCP"
      cidr_blocks = ["${var.mgmt_ips}"]
      description = "Allow incoming SSH from management IPs"
  }

  ingress {
      from_port = -1
      to_port = -1
      protocol = "ICMP"
      cidr_blocks = ["${var.mgmt_ips}"]
      description = "Allow incoming ICMP from management IPs"
  }
  egress {
      from_port = 0
      to_port = 0
      cidr_blocks = ["0.0.0.0/0"]
      protocol = "-1"
      description = "Allow all outgoing traffic"
  }
  tags {
      Name = "SG-Bastionhost"
  }
}

resource "aws_security_group_rule" "lbhttpaccess" {
    security_group_id = "${aws_security_group.WebserverSG.id}"
    type = "ingress"
    from_port = 80
    to_port = 80
    protocol = "TCP"
    source_security_group_id = "${aws_security_group.LoadBalancerSG.id}"
    description = "Allow Squid proxy access from loadbalancers"
}

resource "aws_security_group_rule" "lbhttpsaccess" {
    security_group_id = "${aws_security_group.WebserverSG.id}"
    type = "ingress"
    from_port = 443
    to_port = 443
    protocol = "TCP"
    source_security_group_id = "${aws_security_group.LoadBalancerSG.id}"
    description = "Allow Squid proxy access from loadbalancers"
}

resource "aws_security_group_rule" "webproxyaccess" {
    security_group_id = "${aws_security_group.bastionhostSG.id}"
    type = "ingress"
    from_port = 3128
    to_port = 3128
    protocol = "TCP"
    source_security_group_id = "${aws_security_group.WebserverSG.id}"
    description = "Allow Squid proxy access from webservers"
}

resource "aws_security_group_rule" "dbproxyaccess" {
    security_group_id = "${aws_security_group.bastionhostSG.id}"
    type = "ingress"
    from_port = 3128
    to_port = 3128
    protocol = "TCP"
    source_security_group_id = "${aws_security_group.DBServerSG.id}"
    description = "Allow Squid proxy access from database servers"
}

resource "aws_security_group" "DBServerSG" {
    name = "DBServerSG"
    vpc_id = "${aws_vpc.robertverdam.id}"
    description = "Security group for database servers"
    ingress {
        from_port = 3306
        to_port = 3306
        protocol = "TCP"
        security_groups = ["${aws_security_group.WebserverSG.id}"]
        description = "Allow incoming MySQL traffic from webservers"
    }
    ingress {
        from_port = 22
        to_port = 22
        protocol = "TCP"
        security_groups = ["${aws_security_group.bastionhostSG.id}"]
        description = "Allow incoming SSH traffic from Bastion Host"
    }
  ingress {
      from_port = -1
      to_port = -1
      protocol = "ICMP"
      security_groups = ["${aws_security_group.bastionhostSG.id}"]
      description = "Allow incoming ICMP from management IPs"
  }
    egress {
        from_port = 3128
        to_port = 3128
        protocol = "TCP"
        security_groups = ["${aws_security_group.bastionhostSG.id}"]
    }
    tags
    {
        Name = "SG-DBServer"
    }
}

Defining SSH key-pair

For allowing access to the different compute-instances, we will also define a AWS key pair which allows us to login to the compute hosts via SSH (via a bastion host if needed). First, we have Terraform generate a key-pair which which we ask Terraform to use to create the AWS key pair attached to the instances.  Finally we tell Terraform to output the (sensitive) key on demand (by using the Terraform output command).

resource "tls_private_key" "privkey"
{
    algorithm = "RSA" 
    rsa_bits = 4096
}
resource "aws_key_pair" "keypair"
{
    key_name = "${var.key_name}"
    public_key = "${tls_private_key.privkey.public_key_openssh}"
}
output "private_key" {
  value = "${tls_private_key.privkey.private_key_pem}"
  sensitive = true
}

Define Terraform variables

As you have seen in the code snippets we have used some variables in there. Of course, these variables have to be defined.  The variables are defined by name (i.e. region) and can be provided with a default value (i.e. eu-west-1), if not defined when deploying the application :

variable "region"
{
    default = "eu-west-1"
}

variable "aws_ubuntu_awis"
{
    default = {
        "eu-west-1" = "ami-2a7d75c0"
    }
}

variable "environment"{
    type = "string"
}

variable "application" {
    type = "string"
}

variable "key_name" {
    type = "string"
    default = "ec2key"
}

variable "mgmt_ips" {
    default = ["0.0.0.0/0"]
}

Define Ansible inventory

To be able to use these defined hosts in Ansible I’ve installed the TerraForm plugin provided from https://github.com/nbering/terraform-provider-ansible, which together with an ansible dynamic inventory script from https://github.com/nbering/terraform-inventory/ allows to use the information from the Terraform state as input for Ansible.

We define the information to pass to Ansible as following. We define the inventory_hostname which will be used by Ansible to identify the instance, and the group of hosts the instance will belong to (i.e. security / web / db) and some variables to help ansible find the correct Python interpreter and key to connect to the instance.

ansible_ssh_common_args is used to tell ansible to use an SSH proxy connection to the bastion-host in the specified AZ which then can connect to the compute instances (and for security reasons in my definition only my homelab public IP has access to these bastion hosts).

You also see the use of the privkey.pem below, which you can output from the terraform state by using : terraform output private_key > privkey.pem and then modifying the path in the definitions below:

resource "ansible_host" "BASTIONHOSTA" {
  inventory_hostname = "${aws_instance.BASTIONHOSTA.public_dns}"
  groups = ["security"]
  vars
  {
      ansible_user = "ubuntu"
      ansible_ssh_private_key_file="/opt/terraform/aws_basic/privkey.pem"
      ansible_python_interpreter="/usr/bin/python3"
  }
}

resource "ansible_host" "BASTIONHOSTB" {
  inventory_hostname = "${aws_instance.BASTIONHOSTB.public_dns}"
  groups = ["security"]
  vars
  {
      ansible_user = "ubuntu"
      ansible_ssh_private_key_file="/opt/terraform/aws_basic/privkey.pem"
      ansible_python_interpreter="/usr/bin/python3"
  }
}


resource "ansible_host" "WEB001" {
  inventory_hostname = "${aws_instance.WEBA.private_dns}"
  groups = ["web"]
  vars
  {
      ansible_user = "ubuntu"
      ansible_ssh_private_key_file="/opt/terraform/aws_basic/privkey.pem"
      ansible_python_interpreter="/usr/bin/python3"
      ansible_ssh_common_args= " -o ProxyCommand=\"ssh -i /opt/terraform/aws_basic/privkey.pem -W %h:%p -q ubuntu@${aws_instance.BASTIONHOSTA.public_dns}\""
      proxy = "${aws_instance.BASTIONHOSTA.private_ip}"
  }
}

resource "ansible_host" "WEB002" {
  inventory_hostname = "${aws_instance.WEBB.private_dns}"
  groups = ["web"]
  vars
  {
      ansible_user = "ubuntu"
      ansible_ssh_private_key_file="/opt/terraform/aws_basic/privkey.pem"
      ansible_python_interpreter="/usr/bin/python3"
      ansible_ssh_common_args= " -o ProxyCommand=\"ssh -i /opt/terraform/aws_basic/privkey.pem -W %h:%p -q ubuntu@${aws_instance.BASTIONHOSTB.public_dns}\""
      proxy = "${aws_instance.BASTIONHOSTB.private_ip}"
  }
}

resource "ansible_host" "SQL001" {
  inventory_hostname = "${aws_instance.SQLA.private_dns}"
  groups = ["db"]
  vars
  {
      ansible_user = "ubuntu"
      ansible_ssh_common_args= " -o ProxyCommand=\"ssh -i /opt/terraform/aws_basic/privkey.pem -W %h:%p -q ubuntu@${aws_instance.BASTIONHOSTA.public_dns}\""
      ansible_ssh_private_key_file="/opt/terraform/aws_basic/privkey.pem"
      ansible_python_interpreter="/usr/bin/python3"
      proxy = "${aws_instance.BASTIONHOSTA.private_ip}"
  }
}

resource "ansible_host" "SQL002" {
  inventory_hostname = "${aws_instance.SQLB.private_dns}"
  groups = ["db"]
  vars
  {
      ansible_user = "ubuntu"
      ansible_ssh_common_args= " -o ProxyCommand=\"ssh -i /opt/terraform/aws_basic/privkey.pem -W %h:%p -q ubuntu@${aws_instance.BASTIONHOSTB.public_dns}\""
      ansible_ssh_private_key_file="/opt/terraform/aws_basic/privkey.pem"
      ansible_python_interpreter="/usr/bin/python3"
      proxy = "${aws_instance.BASTIONHOSTB.private_ip}"
  }
}

Deploy application

After defining everything we need to deploy the application-infrastructure we simply run terraform init in the same folder as where you created your TerraForm .tf file to initialize the TerraForm environment:

Then it is time to run terraform plan which tells terraform to see what has to be done to deploy the infrastructure we defined before. Terraform will ask you to input any variables you didn’t define on the commandline (by using the parameter -var <var-name>=<value>)

If the output of the command looks ok, we can then deploy the application to AWS by typing: terraform apply (followed by the same variables) and answering the confirmation to perform these actions with yes (or use the commandline parameter -auto-approve)

Destroying the complete appplication-infrastructure again is even as simple, just replace the apply command with the destroy and your environment gets cleaned up again nicely.

End of part 1

Hope this first post from the blog post series gives you a good insight in how to define an application infrastructure in Terraform to deploy an application on AWS.

In the next post we will see how to use the information from Terraform in Ansible to do further configuration of the compute instances.

Any comments, questions, tips&tricks are welcome, so please feel free to contact me! 

The post Deploying an application to AWS with Terraform and Ansible – Part 1 (Terraform) appeared first on RobertVerdam.eu.

Recently I was invited to join the beta of the new Ravello platform which also allows to run these Ravello workloads on Oracle’s own cloud (Oracle Cloud Infrastructure) and test how the new additional modes of running Ravello increases performance for the workloads.

DVDStore v3 Benchmark

I decided to do a DVDStore3 performance benchmark first by running it in each ravello mode.  For more information about the different Ravello modes scroll down to the next paragraph.

So first I spun it up on the West Europe 1 and US East 2 region, which uses the ‘tradional’ Ravello mode of software assisted nested virtualization (by binary translation).

After this I spun up the same DVDStore3 application on the US East 5 region (which is the Oracle Cloud Infrastructure region). This allows us to see the performance benefits of running the workload with Hardware Assisted Nested Virtualization instead of Software assisted virtualization.

Doing the tests on the different regions was as easy as creating a blueprint from the application, create an application from the blueprint and then republishing it to the dedicated region for this beta test (US East 5). So a few clicks and I had the application runnning on another region & cloud. This is also what I find to be a enormous benefit of Ravello.

Finally I ran the same application on bare-metal (which is the Ravello HVX-hypervisor running directly on the Oracle Cloud Infrastructure), by modifying the PreferPhysicalHost=true parameter of the app-VM and restarting it.

I ran the tests for an hour in each mode and noted the results, which are the total amount of orders processed in an hour.

Although i’ve used a simple test setup, because of the fact test setups are identical (vCPU, RAM, etc.) the test in my opinion gives a fair representation of the different modes Ravello can run in and which relative performance improvement you can get from running your workloads with Ravello running on Oracle’s own cloud infrastructure instead of on AWS / GCE with binary translation.

Ravello Modes

As promised some more clarification on the 3 modes Ravello can run your unmodified VMware workload in, depending on the cloud the application is published to:

• Software assisted nested virtualization by binary Translation
  Ravello running on AWS, GCE and OPC:
  Used when the underlying clouds where the hardware virtualization extensions are not available, HVX uses a software based nested virtualization technology called binary translation with direct execution to run the VMware VMs. This technology offers good performance that is acceptable for a wide variety of the workloads.
• Hardware Assisted Nested Virtualization
  Ravello running on Oracle Cloud Infrastructure:
  Oracle Cloud Infrastructure runs on the next generation of blazing fast hardware that supports virtualization extensions. These extensions allow multiple guest operating systems to share the same underlying hardware in safe and efficient manner. HVX utilizes these hardware assist CPU instruction sets to perform its nested virtualization directly on the underlying cloud hardware and offers significant performance improvements over the previous generation of HVX. Typically, the cloud providers do not expose the hardware assisted virtualization extensions to the guest VMs, which limits the performance that customers can realize when operating in a nested virtualization mode. However, with Ravello running on Oracle Cloud Infrastructure, we now have complete access to these hardware assist virtualization extensions, and can make performance boosts a reality.
• Bare-Metal
  Ravello running on Oracle Cloud Infrastructure, directly on HVX:
  HVX also supports the ability to run directly on top of bare metal servers. By eliminating a layer Hardware assisted nested virtualization –  of hypervisor in the middle, HVX is able to provide near native performance.

A graphical representation of the explanation above:

DVDStore

So what is this DVDStore you’re running these tests with?

I couldn’t come up with a better explanation of what is then quoting what the author says that it is:
DVDStore 3.0 ( Source: Github )

DVD Store 3 (DS3) is an open source test / benchmark tool that simultaes an online store that sells DVDs. Customers can login, browse DVDs, browse reviews of DVDs, create new reviews, rate reviews, become premium members, and purchase DVDs. Everything needed to create, load, and stress this online store is included in the DVD Store project.

I set-up a simple Ravello application which consists out of a DB/App/Webserver-VM (DB) on which a driver-VM (MGMT) simulates the OLTP-workload. I used DVDStore with a medium-sized database (10GB) and used the following settings for the web-driver running the workload on.

target=DB
n_threads=100
ramp_rate=1000
run_time=60
db_size=10GB
warmup_time=5
think_time=0
pct_newcustomers=20
n_searches=3
search_batch_size=5
n_line_items=5
virt_dir=ds3
page_type=php
windows_perf_host=
linux_perf_host=
detailed_view=Y
out_filename=results.txt

DVDStore performance benchmark results

The following (interactive) graph show the results which were obtained from the benchmarks described previously and show the performance for the different Ravello modes and especially the performance improvement running the workloads on Ravello on Oracle Cloud Infrastructure, which show it to be twice as fast (for this DVDStore3-application):

Running ESXi on ‘bare-metal’ Oracle Cloud Infrastructure

Besides the above performance benchmark testing, I also have a ‘full’ ESXi 6.5/NSX lab running on Ravello, which I dediced to spin up on the new ‘bare-metal’ option (with HVX running on bare-metal) with ESXi on top.

I noticed significant performance improvements for the nested VM’s running within my nested ESXi environment, as previously with binary translation it made it almost unpossible to use by the many layers of nested vitualization made it very slow using these VM’s.

Increased VM size

Good to mention is that the max number of vCPUs that you can assign to a VM running on Ravello on Oracle Cloud Infrastructure, has also been increased from 8 to 32 and the vRAM-size has gone up from 64GB to 200GB. So potentially it would be possible to run the benchmark with more power and squeeze out some more performance.

Besides that it allows to run quite a decent homelab :).

Conclusion

Running the DVDStore3-benchmark on Ravello on Oracle Cloud Infrastructure shows significant performance improvement and doubles the orders processed in an hour for the DVDStore3-application. The performance running the benchmark on bare-metal HVX was even better.

Running my ESXi-lab on Ravello on Oracle Cloud Infrastructure sure gives additional performance and makes it very usable as a replacement for my homelab.

Thanks again to Oracle for providing us vExperts with this free service again this year. Would be fantastic if we could keep on using the new Ravello Modes for homelab usage next year!

More information

Interested in trying Ravello on Oracle Cloud Infrastructure?
Free trial is available if you follow this link or you can drop them a line on ravellosales_ww_grp@oracle.com

If you have any questions on Ravello and / or running it on Oracle Cloud Infrastructure, please feel free to contact me!

The post Ravello on Oracle Cloud Infrastructure appeared first on RobertVerdam.eu.

For more information about these certifications please have a look at this page dedicated to the certifications currently available.

I’m proud to have passed the exam and now am an Veeam Certified Architect!

VMCE-ADOv1 Course

Really enjoyed the 2-day course delivered by Bart Pellegrino (via Copaco / @Academy), as it was a good mix between theory, interactions between teacher/students and students/students and whiteboarding. The whiteboarding sections consisted out of 2 design scenario’s, in which the focus was on how us students figured out a way to fulfill the requirements of the client in our designs. It was not about what the solution finally turned out to be, but the thinking process behind getting to the designs.

The training really was an interactive experience and no one-way traffic from teacher to students. Wish every training could be like this!

The interactions where really insightful as they contained lots of practical examples, about how to design a Veeam-solutions in real life and what pitfalls to watch out for and lots of alternative solutions to problems. The training really strengthened my understanding of the Veeam Availibility Suite and gave me tools to design & optimize the environments even more in the future.

To give you an idea of the topics covered during the Veeam Certified Engineer Advanced : Design & Optimization training, I provided a short overview of the contents of the training below.:

Training Day 1

• Design and Sizing
• Infrastructure assessment
• Security
• Design Scenario: Part 1

Training Day 2

• Optimizations
• Design Scenario: Part 2
• Automation
• Audit and Compliance
• Troubleshooting

Exam Day

I decided to do the exam just for I go on holiday, just to be sure the training material from the course was still fresh in memory. Because the exam of course is under NDA, there is not much I can say  about the contents.

I think the (multiple choice / Select 2/3) questions on the exam are fair, but it’s very helpful to have practical experience with designing, optimizing and troubleshooting real Veeam environments, as some questions just dig deep into your insights into how Veeam Backup & Replication and Veeam One work.

Overall this was one of the more challenging exams I have taken recently, so I’m very happy I PASSED the exam with a whopping score of 86%.

Training Materials

Preparing for the exam I used the following training materials (in order of importance to me):

• VMCE-ADOv1 Textbook
• VMCE-ADOv1 Handouts
• Information @ Backitup.online (Bart Pellegrino)
• Veeam Best Practices Guide
• VMCE v9 textbook

The exam simulator (practice exam) on Bart Pelligrino’s site provides a good insight in the way the questions on the exam are asked, so please give it a go. It also gives a good idea on which area you need to focus more after attending the course.

After day 1 of the training I already scored 63% on the practice test and after day 2 and some studying of the training-material already 83%. The exam itself I passed with 86%, so to me this proves the exam simulator gives a good representation of where you stand in the process of being able to pass the exam.

The post VMCE-ADOv1 (exam) experience appeared first on RobertVerdam.eu.

Thanks for supporting Cloudfix! The least we can do is write a introductory  blog about their backup & replication solution for VMware. So this is not a full review of all the features of the product, but I hope it gives you a good glimpse of the product and I get’s you interested to do some further investigation into their products.

Besides a backup solution for VMware environments, NAKIVO is also offering a solution for backing up AWS-instances, so if you’re looking for a solution for backing up and recovering your company’s EC2 instances, please give their website www.nakivo.com a visit.

Deployment

NAKIVO Backup & Replication for VMware  can be deployed in a couple of ways:

• Virtual Appliance (OVF)
• NAS
• AWS Amazon Machine Image
• Linux-/Windows installer

In my CloudFix lab I used a standard script to deploy the OVA to my lab-infrastructure via PowerCLI, which can be found below. I decided to put the DATA-vmdk (which NAKIVO uses for it’s repository) on a seperate (USB) datastore, so the backup data is seperated from the production data :).

& 'C:\Program Files (x86)\VMware\Infrastructure\PowerCLI\Scripts\Initialize-PowerCLIEnvironment.ps1'
 # Defines the used credentials to connect to the vCenter
 $Deploy_Username_VC = 'administrator@vsphere.local'
 $Deploy_Password_VC = 'VMware1!'

# Defines the datastore to which to deploy the VM
 $Deploy_To_Datastore_VM = 'NAS-VM'

# Defines the datastore to move the data-VMDK to
 $Deploy_To_Datastore_Data = 'NAS-USB-02'

# Defines the VM-name to use for this NAKIVO B&R Appliance
 $Deploy_To_Name = 'TH-NAKIVO-02'

# Defines the Port-Group to connect the VM to
 $Deploy_To_PG = 'RV-Prod'

try{

$ViServer = Connect-VIServer -Server $Deploy_To_VC -User $Deploy_Username_VC -Password $Deploy_Password_VC
 $OVF_Config = Get-OvfConfiguration -Ovf $Naviko_OVF_Location

# Set network to deploy to this network
 $ovf_config.NetworkMapping.VM_Network.Value = $Deploy_To_PG

# Import OVF
 Import-VApp -OvfConfiguration $OVF_Config -Source $Naviko_OVF_Location -VMHost $Deploy_To_Host -Datastore $Deploy_To_Datastore_VM -DiskStorageFormat Thin -Name $Deploy_To_Name

# Move Data disk to other datastore if needed
 if ($Deploy_To_Datastore_VM -ne $Deploy_To_Datastore_Data)
 {
 Get-HardDisk -VM $Deploy_To_Name -Name "Hard disk 2" | Move-HardDisk -Datastore $Deploy_To_Datastore_Data -Confirm:$false
 }

# Start VM
 $vm = Start-VM -VM $Deploy_To_Name

# Wait for guest heartbeat
 while ( (get-vm -Name $Deploy_To_Name | Get-View).GuestHeartbeatStatus -ine 'green')
 {
 Write-Host "Waiting for VM to respond to heartbeat"
 Start-Sleep -Seconds 5
 }
 }
 finally
 {
 Disconnect-VIServer -Force
 }

VMware Backup

NAKIVO runs all backup jobs in a incremental-forever fashion to a backup repository. This backup repository can be located on a storage local to the assigned transporter (which moves the data to the backup repository), a remote CIFS / NFS share or Amazon EBS (Elastic Block Storage) via a transporter deployed as Amazon EC2 instance.  The inital transporter is included with the installation of the virtual appliance.

These backup repositories can be setup to :

• Compression
• Global (data)-deduplication
• Encryption for the data at-rest.

The VM data can be accessed by the transporters in three ways:

• Direct SAN mode
  The SAN mode leverages VMware VDDK library to mount the LUN’s directly to the transporter). This allows you to directly read the VM data from the source-LUN via the FC / iSCSI storage network.
• Hot-Add
  When using the virtual appliance as a transporter, hot-add mode can be leveraged to attach the (snapshotted) vmdk directly to the transporter and reading directly from the VM’s VMDK.
• LAN
  If the methods above are not available, data can be read via NBT (Network Block Device Transport), reading the data via the LAN (VMkernel interface which is assigned for NFC (Network File Copy).

The primary backup jobs can be setup to use GFS rotation scheme directly (so no backup copy jobs needed to set this up).

Backup copy jobs can then be used to create a additional copy of the backup data (for example for offsite storage).

Recovery Options

NAKIVO Backup & Replication offers the following options to recover data using the VMware VM Backups:

• Flash VM Boot
  Flash VM boot allows to spin-up the VM directly from the backup repository by letting the transporter expose the VM via iSCSI to a vSphere-environment. When you start a job you select the datastore to which the VM writes the changes of the active VM. This feature can also be leveraged to do backup verification or as a lab-environment for testing application patches. Also it’s possible to Storage vMotion the VM back to it’s original location while it’s being run from the backup repository while using iSCSI. When discarding the VM (when ending the Flash VM Boot session it will only remove the snapshot it created when starting the VM from the backup repository).
• Instant File Recovery
  Using a web-based file recovery wizard files can be recovered by forwarding it via email / downloading it (as a zip-file) from the web browser and recovering it manual to it’s original location or whatever you want to do with the files.
• Instant Active Directory / Exchange Objects Recovery
  For supported application databases (AD via ntds.dit and Exchange) application-item level recovery can be done. For Active Directory these objects can be forwarded via email or downloaded as a zip file (which then contains a ldif, which can be imported into the AD to recover the selected products). Unfortunately I have to Exchange environment currently in my lab-environment, but my guess is the restore works the same way. So selecting the objects you want to recover and them forward them by mail or download to then manually recover them on the specific application.

For both the instant file recovery and the instant application-item level recovery I would to love to be able to restore it directly back to the VM (using guest credentials if needed) and to be able to search through multiple restore points for specific files and versions of these files.

Replication

NAKIVO Backup & Replication also support replication of VM’s and even allows you to keep 30 restore points to revert your replica to and apply GFS (GrandFather – Father – Son) logic to it. So these replicas can also be used as an additional source for recovery of backup data. These replication jobs can also leverage VMware features like CBT and VMware Tools quiescing, just like the backup jobs. Ofcourse these replicas can be used for DR-purposes (with Failover and Failback capabilities built into the product). Also basic verification can be set up (just as for the other jobs) which sends you a screenshot of the booted VM (with network detached from the VM).

Also the replica’s can be pre-seeded using removable media and resume the replication with incremental replication afterwards.

If we use an additional transporter for these jobs we can also apply network encryption and network acceleration to the data while in transit.

Conclusion

I like the ease of deployment of this product and the clean interface it has, which allows you to have the product setup and running in no time.

I would really encourage you to give NAKIVO Backup & Replication 6.2 a go, if you’re looking for a easy to implement solution for your (small to medium-sized) VMware environments.  You can sign up at https://www.nakivo.com/vmware/vmware-backup-trial.html for a free trial and give it a go yourself to see if the feature-set is sufficient for your backup and replication needs.

Hope you liked this quick review.

Happy holidays!

The post Quick review: NAKIVO Backup & Replication 6.2 appeared first on RobertVerdam.eu.

It gives you a easy way to extend your private on-premises DC to the AWS cloud and have uniform central management plane, leveraging vCenter Enhanced Linked Mode across all your (public & private) vCenter-servers. One of the coolest things which we witnessed was now really moving a VM from your on-premises and totally moving it to AWS with XvMotion-technologies

  Getting started

Deploying your VMC is as easy as following these steps:

1. Logging in to VMware-Cloud portal (TBD determined: vmc.vmware.com)
2. Selecting your (initial) virtual datacenter size
3. Enter your Payment details (CC / VMware-account)
4. You’re good to go!

Elastic DRS

VMware Cloud on AWS gives us a new capability which gives us a solution for a couple of problems we are facing in a vSphere environment. It adds elasticity to DRS, which allows DRS to auto-scale the amount of hosts you are running for your vSphere-cloud running (with set minimum and maximum amount of hosts it’s allowed to spin-up in your VMC). So if DRS detects the cluster being imbalanced it automatically spins up a new ESXi-host, add it to your cluster, move workloads to this new host and get the cluster balanced again within no time. This works scaling the cluster up, but also for scaling the cluster down. So no more waiting 6 weeks for getting a new server ordered and racked up and then finally adding it to the cluster. By then your cluster already overloaded or the load is already gone. Just get the resources you need at any time. Obviously the VSAN-datastore is also extended with every host that’s added to the VMC-cluster. So if you need more capacity on the storage component you just add another host to the cluster.

This reduces the capacity planning you have to do for your vSphere-environment hugely.

Auto Remediation

Besides capacity management, HA will be leveraged for auto remediation. When a failure occurs on a host within a cluster it will automatically be evacuated (vSphere maintenance mode and VSAN entering maintenance mode and evacuating from the cluster), a new host started and the workloads restarted on this host. If VSAN FTT (Faults-to-Tolerate) is violated another host is added to fix this automatically.

Improved Uptime and Performance

VMware will take care of patching the ESXi-hosts in your VMC cluster and will guarantee you’re having the amount of resources you’re paying for. Cluster size is not affected during these rolling updates / upgrades. VMware will have you on the latest and greatest (stable) version which is available. So no more patch management for your vSphere-environment.

Timeline

VMC for AWS will be entering the beta phase in the beginning of next year. Can’t wait to do some beta testing. GA will be somewhere mid-2017. Will it be announced GA at VMworld Las Vegas?!

More information

If you’re looking on more information on VMware Cloud on AWS check the following sources:

• https://blogs.vmware.com/vsphere/2016/10/vmware-cloud-on-aws-a-closer-look.html
• @vmware_vmc (twitter)

The post VMworld EMEA Announcements: VMware Cloud on AWS appeared first on RobertVerdam.eu.

VSAN Version History

To give a idea what the main new features were in the previous releases of VSAN here, a short overview:

We really enjoy the pace in which this product is being developed and in such a incredible pace. Keep it going guys!

The main new features for this 6.5 release which is announced during VMworld EMEA 2016 (Oktober 2016) according to us among others are:

• iSCSI-Access
• Direct Connect for ROBO

iSCSI-access

VSAN target service makes it possible to use a VSAN as a iSCSI-target (what’s in a name!) and allows these targets to be presented to external (non-virtual) workloads (i.e. MSCS clusters or physical workloads). So no more need for additional storage boxes to tie to your (legacy) physical workloads, you can now also use VSAN for these workloads.

Also allows for SPBM (Storage Policy Based Management) for these targets, so you can set dedup / compression / raid-level (1,5 or 6) and applies them respectively to these iSCSI-objects in your VSAN-datastore.

Direct Connect for ROBO

VSAN 6.5, allows for directly connecting to VSAN-nodes together in a ROBO-situation with a couple of crossover-cables which lifts the need for 10Gb network switching connecting the nodes.You can now suffice with only 1Gb-switching for management and witness traffic. So it simplifies the set-up and decreases the cost for setting up VSAN 6.5 for remote offices.

Further improvements

A short list of other enhancements / changes in the VSAN 6.5-product:

• All-Flash now available in VSAN STD license (Compression en Dedup still needs ADV/ENT-licensing) and new VSAN ADV for ROBO offering.
• Containers support. VSAN allows as a source of persistent storage for VIC (vSphere Integrated Containers)
• Updated REST API and extended PowerCLI module for VSAN
• Enhanced hardware support

More information

For more information on the new Virtual SAN 6.5, have a look at the following links:
http://www.vmware.com/products/whats-new-virtual-san.html

The post VMworld EMEA Announcements : VSAN 6.5 appeared first on RobertVerdam.eu.

vCenter Server (Appliance) 6.5

VMware is dramatically simplifying the experience using the vSphere-platform which is primarily based on the announcement of vCenter Server Applicance 6.5 and it’s new capabilities which are exclusive to the vCenter Server Appliance.

The VCSA-only features which are new to 6.5 are:

• Native High Availability
  Active/Passive HA solution with a witness for resolving split-brain situations. The setup requires 2 separate networks (Private vs. Public). The private network is used for HA (routed)-traffic between the both VSCA which consists of (sync) DB and (async) file-replication. This gives us a easy way to set-up a high available vCenter server.
• (Integrated) VMware Update Manager
  VMware Update Manager is now finally integral part of VCSA, so no more managing a seperate Windows VM for using VMware Update Manager.
• Improved Appliance Management
  Increased insight into how the appliance is doing CPU-, Memory-, Network- and databasewise. This reduces having to rely on the CLI for simple monitoring task on the VCSA and allows do this via the UI (VAMI). A thingy called vMon enhances the watchdog functionality which is also used for determing which host is active and which is passive when using VCSA in a HA-setup.
• Native Backup & Restore
  Native file-based backup & restore capabilities built-in to the VCSA, which allows backing up via HTTP(s)/FTP(s)/SCP protocols and restoring the state of a VCSA to a (fresh) appliance.  All this happens from within the VAMI (Virtual Appliance Management Interface). It evens allows for restoring the configuration when installing the VCSA via ISO.

The new VCSA-installer gives us an additional set of options for setting up VCSA. Besides Installing and upgrading a VCSA, it now also adds the options to migrate to VCSA from a current embedded/external windows-based vCenter Server (5.5 or 6) setup. The VCSA assumes the old personality (i.e. UUID, IP, Name and certificates) of the windows-based setup and the databases are migrated to Postgres. Serveral options are included for which further data (Configuration, Events and Tasks and/or performance metrics) is migrated. Futhermore is the installer not only supported on Windows, but also on Linux and Mac and runs on top of Photon OS.

vSphere Client (HTML 5 Web Client)

VMware is using a new standard framework for UI/UX (Clarity UI) which it’s converting all it’s products to. The first product being published which is based on this new framework is the new vSphere HTML 5 based client which is now integrated into vSphere 6.5. The new HTML5-based web client started out as a fling VMware has developed earlier in their labs. So no more browser plugins needed and a great user experience awaits. VMware still really appreciates your feedback, so if you care to share some feedback with VMware, please hit the nice little smiley-face in the upper-right corner to make this product even better!

Enhanced Lifecycle Management

VMware also added some little nifty enhancements to their products which make the life of us Virt-Admins a little easier. Amongst others (a lot of enhancements were announced) these are the features that stood out to me:

• Default cluster remediation options (Update Manager)
  Possible to now save cluster remediation options as a default, so you don’t have to set them again and again when doing a rolling cluster upgrade. But now you can just fire away with the settings you used previously.
  
• Filtering settings in Host profiles
  VMware added a search box which makes it very easy to look for certain settings within your host profile. This saves you a a lot of time clicking through the tree to find the right setting for setting the location where your VMware-tools depot is located, which you always forget (like me) where it was exactly located.
  
• Bulk modification of host profile customizations
  For management at scale purposes you’re now able to bulk export alle the host profile customizations as a CSV, edit them and reimport them and voila you’ve got your host profile customization set-up in bulk!
  
• Detailed compliance reporting and proposed changes for host profiles
  It will now become very easy to see what settings will be changed on a certain host when remediating those hosts. No more guessing or searching for wat settings will get changed, but vSphere will tell you up front when you are scanning or remediating the hosts.

Hopes this gives you an idea of what kind of enhancements VMware has made in their vCenter product. If any more nifty features pop-up during VMworld or any sessions we attend we’ll keep you updated ofcourse!

Check the following link for VMware official blogs about the newly released solutions:  http://www.vmware.com/company/news/releases/vmw-newsfeed.VMware-Advances-Cross-Cloud-Architecture-with-New-Releases-of-vSphere,-Virtual-SAN-and-vRealize-Solutions-to-Drive-IT-and-Developer-Productivity.2104600.html

The post VMworld EMEA Announcements : vSphere 6.5 appeared first on RobertVerdam.eu.

Questions

Who is Daniel Zuthof?

I am an IT enthusiast living in Enschede with my wife and 2 young kids. In my spare time I love to spend time with my family, friends, ride my motorcycle and road bike as often as possible.

After finishing school at age 20 I started working at several employers of which all are in IT. The first was at a local IT firm in the city I lived in at the time. Afterwards I worked at several larger businesses in the Arnhem and Utrecht area. Before starting at Equinix, I worked in the IT department of the hospital in Enschede as senior systems engineer.

Can you tell us something about your employer/company?

I work at the Managed Services department at Equinix. Equinix is the world largest suppliers of carrier neutral datacenters and operates 145+ datacenters across 5 continents in 40 metro areas. In The Netherlands, Equinix operates 10 datacenters of which 1 is currently being build.

The main business consists of housing, inter rack connections, inter metro area connections, inter country connections, direct public cloud connections (Equinix Cloud Exchange) and internet connections.

The Managed Services department designs, builds, operates and supports IaaS and PaaS platforms for customers inside our own datacenters. Besides building dedicated platforms according to customers specifications we also operate our own Equinix Business Cloud (EBC) IaaS platform, which is located in 3 datacenters across The Netherlands. Other products we sell are security & storage solutions and back-up &  replication services.

Can you describe your IT infrastructure in short?

We operate IaaS and PaaS platform of every scale. One of them is the Equinix Business Cloud (EBC). Without going in too much detail the EBC platform is operational in our Enschede, Zwolle and Amsterdam datacenters. The 3 sites are well connected in a redundant way. In each of the sites a VMware based independent IaaS platform is operated which is managed by using a common management layer. If required by a customer, complete site redundancy solutions can be offered.

What is the main purpose for this IT platform?

The EBC platform is primarily designed for customers who do not want to operate their private (on-premises) cloud platform. They want to extend their existing platform without investing in new hardware and find it important to know where their information is stored.

The storage layer is based upon a multi-tenant scale out design. This makes it easy to add additional capacity and it can deliver specific tiers up to a guaranteed 10K IOPS level. The EBC platform makes it possible for our customers to connect to the EBC network and consume compute and storage independently from each other in all 3 sites.

If you had the chance to design and build this environment all over again, would you change anything? If so, what would you do differently?

As a matter of fact, the EBC platform is just rebuild using the latest 100GbE networking technology using overlay networks and multi-tenant scale out storage. This makes it possible to scale the platform to the next level while lowering operational efforts.

The next focus will be on cloud scale automation and further implementing the network overlay techniques into the platform.

What are new developments or solutions which caught your eye and why?

I’m interested in a lot of great techniques. A quick summary would be cloud native apps, storage, cloud management products, network virtualization and automation.

What are your thoughts on applying these on your own environment?

To be able to serve our customer at the levels they deserve now and in the future, network virtualization and automation products are key to the infrastructure. Network virtualization is important for hypervisor based routing and firewalling. Also the micro segmentation and hybrid cloud possibilities are important for us as a service provider.

For the automation part, the operability with the virtualization solution is important since these two work closely together. Automation lowers the operational costs and implementation time while quality is increased.

How do you see IT change in the next 5 years?

Cloud native apps will be a greater part of the IT landscape. More companies will move towards the DevOps style of managing their environment, which aligns to the agile framework where more and more companies move to.

How do you think this will translate to your current working environment?

Equinix will embrace the changes to be able to serve our customers the best way possible.

What’s the greatest tech disruption you’ve seen in your career?

I would say cloud computing in general. This manner of looking to IT provided services changed everything in the last decade. Combined with virtualization on the compute, storage and network layers, the possibilities are endless for those who are open for it.

What would you do for a living if you had not ended up in IT?

Probably I would be cook or electrician is some way. Those two appealed to me in my teenage years, besides computer technology. When looking back with my current knowledge, I would not choose another type of job. Working in IT is one of the most challenging in any aspect if you are open to it. The industry is so innovative and new product and techniques are released often which requires you to rethink designs and solution regularly.

Thanks for sharing your thoughts with us!!

The post Interview Series: Daniel Zuthof appeared first on RobertVerdam.eu.