• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

vFrank

Essense of virtualization

  • LinkedIn
  • RSS
  • Twitter

vCloud

vCenter er nede, hvad gør du?

November 3, 2017 by FrankBrix Leave a Comment

Hvad ville du gøre hvis dit vCenter blev utilgængeligt i morgen og hvilken indflydelse ville det have på din forretning? Svarene falder typisk i to kategorier:

  • Mit vCenter er ikke kritisk for min produktion og hvis det er nede installere jeg blot et nyt og forbinder det til mine ESXi servere.
  • KRISE! Hvis mit vCenter er nede er der ikke self-service, overvågning og styring af de virtuelle resourser. Jeg er på dybt vand!

Det er er en gammel kendt udfordring i et hvert datacenter. Hvordan beskytter man sin VMware mangement stack og får den hurtigt online igen med en lav RTO. VMware udvider sine management produkter. Hvor man tidligere kunne nøjes med en enkelt vCenter server består de fleste miljøer af adskillige servere til håndtere den daglige drift og rutiner. Den er i dag udbygget til:

  • vCenter (med intern eller ekstern database)
  • vRealize Operations Manager
  • vRealize Automation Center
  • vReaize Log Insight
  • NSX Manager
  • PSC (platform services controllers)
  • SDDC (VMware Cloud Foundation)
  • Management AD og DNS

Udover disse VMware services er der også flere administrative servere som IT afdelingen er afhængige af som kan tilføjes som kritiske komponenter til en disaster plan. Med det Software Defined Data Center er det ikke som tidligere hvor vCenter var “nice-to-have” – er det nu blevet til en kritisk funktion der altid skal være online. Hvis vCenter er nede skaber det problemer for ting som

  • Selv-provisionering af nye virtuelle maskiner
  • Overvågning
  • 3′ parts produkter der kommunikerer med vCenter

I et tilfælde hvor der er nedbrud eller datatab på management stacken er man ilde stedt. Hvordan bringer man stacken online når vCenter og evt. management AD og DNS er nede? Er din platform til beskyttelse 100% uafhængig af dem? Med stor kompleksitet er det muligt at bygge et system med traditional software som kan håndtere dette. Men hvordan tester man det? Hvordan sikrer man at alle windows servere benytter lokale service accounts og ikke AD konti? På hvilken måde kompromittere dette sikkerheden? Hvad med faren for Ransomware når traditional software kører på Windows og i værste tilfælde bliver backup data kryptereret og utilgængelig?

Til at løse dette er der behov for at se på problemet med friske øjne. Der er behov for en løsning der opfylder følgende

  • Baserer sig ikke på Windows og backup data er immutable
  • Har ingen afhængigheder af AD og DNS
  • Kan benyttes selvom vCenter er utilgængelig
  • Kan udføre en Instant-Mass-Restore og bringe ALLE administrative servere online med det samme og som en gruppe.
  • Simpel og alt inkluderet i et system (ikke 4-5 forskellige produkter og producenter)
  • Ingen single point of failures.

Hos Cohesity løser vi dette elegant og din management stack er beskyttet og muligt at lave recovery på få sekunder. De unikke funktioner ved Cohesity:

  • Policy baseret beskyttelse
  • Alt-i-et-system (de-dupe storage, backup software, databaser, always-online, fuld HA for alle komponenter software og hardware.)
  • Instant-Mass-Restore: Recovery af 5 eller 50 maskiner på få sekunder
  • SnapTree: Alle backup punkter er fully hydrated og instant-recoverable. Ingen baggrunds IO operationer for at lave syntetiske fulls
  • Test/Dev: Mulighed for at teste recovery når som helst og validere det virker

Hvis du ønsker at få en demo at dette i dit eget datacenter så tag kontakt.

Hvis du vil læse mere om hvordan Cohesity beskytter den fulde VMware Management Stack inklusive cloud foundation så læs mere her:

http://www.cohesity.com/vmware-cloud-foundation-vcf-cohesity-white-paper/

Video Demonstration:

https://www.youtube.com/watch?v=jtAoCi4HcX4

Filed Under: certification, Cohesity, Network, PernixData, SSO, Uncategorized, vCloud, vcops, View, vMotion, vSphere

High Availability in a vCloud Director Environment

May 22, 2013 by FrankBrix 2 Comments

High Availability in a vCloud Director Environment

 

Making sure your cloud is accessible, at all time,  to end users and administrators is an important task. When looking into a cloud based on VMware vCloud Director there are several things to take into consideration. A VMware vCloud can consist of a lot of components. The mandatory components are the following

  • VMware vCenter Server (Typically Windows 2008/2012 or Linux Appliance)
  • VMware ESXi hosts
  • VMware vShield Manager (Linux Appliance)
  • VMware Director cell (Red Hat Enterprise Linux)
  • Database Server for vCenter and vCloud Director

Optional Components

  • vCenter Chargeback
  • vCenter Operations Manager
  • vCloud Automation Center
  • VMware Orchestrator
  • …

You have to think about how you want to protect the mandatory and optional components. I will focus on the mandatory now.

VMware vCenter Server

There are different ways to protect the vCenter Server. But before you think about protection you need to think about how you are going to deploy it. Your first option is am I going with the Windows version or going with the Linux appliance. In most cases people go for the Windows version, and that is definitely the safe bet. One of the things the Linux appliance has against it is only support for external Oracle databases. No MS SQL support.

If you choose the Windows version you have to consider if you are a splitting the vCenter roles up on multiple virtual machines. The roles you are considering are the following: SSO, Inventory Service, vCenter Service and Update Manager. For best performance and scalability you would split it up. But that also means you have to consider how to protect each server.

SSO has its own “clustering” functionality. But Inventory Service and vCenter does not. In most situations the software is installed inside a virtual machine running on a ESXi host with VMware HA enabled. This means you don’t need to worry about physical server failure. But it does not protect you against a failure on the software side that could be related to the Operating System or vCenter itself. If you figure out you want to go beyond hardware failure your only option is to deploy VMware vCenter Heartbeat. Heartbeat is able to protect all servers running SSO, Inventory Service and vCenter Service. It does it by replicating the server to another virtual or physical machine. Heartbeat is the tool if you have very strict SLA agreements. It will make your system more secure, but it will be on the cost of losing simplicity.

ESXi hosts

The ESXi hosts are the easiest to protect, and you don’t have to do a lot of planning in this area. Just make sure you have multiple ESXi hosts. All connected to the same network and access to the same shared storage. This way the virtual machines can gets it compute resources from any host in the cluster. On that cluster you will enable the DRS and HA functionality. I would not even worry about backing up the ESXi hosts. If you lose a host just reinstall it.

VMware vShield Manager

The vShield Manager comes as a virtual appliance from VMware. You simply download it and import into your management cluster. There is no native clustering functionality so you have to rely on VMware HA or VMware Fault Tolerance.

VMware Director Cell

The vCloud Director software has to be installed on a Linux machine running Red Hat Enterprise. Luckily for us the software has its own clustering functionality. What you basically do is install multiple Red Hat machines. All of these machine will share the same database on MS SQL or Oracle and the will also have access to the same NFS share. When implementing multiple vCloud Director Cells you would deploy the behind a load balancer. That load balancer could be VMware vShield Edge or you could use something else like Netscaler, F5 etc.

Database Server

The database server is extremely critical in the vCloud Environments. If we are only looking at the mandatory components you will have created three databases on your server. One for the SSO service, One for the vCenter Service and One for the vCloud Director Cell.

What you would normally do with your database is to look into clustering the MS SQL or Oracle with its own tools. If you don’t want to cluster the database. At least make sure that it is running as a virtual machine so you get the benefit of VMware HA. And of course remember to backup all databases at a regular interval.

If you are using a MS SQL cluster you have to know that it is not “officially” supported by VMware for the SSO service. Although they will do their best to help you if you have problems. I have installed all of the components against a MS SQL Cluster and haven’t experienced any problems yet. But we aware of this and set it as a risk.

Filed Under: vCloud, vSphere

IP Masquerade on Edge Gateways in VMware vCloud Director 5.1

November 5, 2012 by FrankBrix 1 Comment

Last week I was helping a customer with installing and configuring VMware vCloud Director 5.1. Things were going pretty smooth until I noticed that we could not get any traffic to get out of the organisation to the external network. The Organisation network was connected to a Edge Gateway but it did not let any traffic through. In vCloud 1.5 this just worked out of the box. It used to have IP Masquerade and NAT enabled per default. After some troubleshooting we figured this was not the case in vCloud 5.1 on Edge Gateways. To enable IP Masquerade and NAT you have to do the following.

  1. Sub allocate an IP pool to the Edge Gateway
  2. Create an SNAT rule on the Edge Gateway 
This was pretty easy but it simply did not work! We tried a lot of things and we finally got it to work by editing the vShield Edge Gateway through the vShield Manager Web Interface. First you have to find your machine in the vShield Manager. When you have found it you need to edit the vnic0 and add an extra external IP address. See screenshot.
 
 
Then you need to go back to the vCloud GUI and create the SNAT rule. See second screenshot here:
 
 
you can not use the first IP address of the Edge Gateway for IP Masquerade. You need to add another one. By doing this simple configuration you now have NAT and IP Masquerade services running on your Edge Gateway. Check out the following KB document
 

Filed Under: vCloud

vCloud Fencing

March 1, 2012 by FrankBrix 17 Comments

VMware vCloud Director has several use cases. One of them is to use vCloud director for “lab management” purposes. For instance you can run several vApps simultaneous with the same IP and MAC addresses completely isolated or “fenced” We are currently building our own vApps for VMware training purposes. The ability to build one vApp for one student – add it to the catalog and then deploy it X amount of times is essential in our environment. 

To understand fencing in vCloud Director you really need to understand the basic network concepts in vCloud director. vCloud director has three kind of networks

External Network: This is basically a portgroup on a standard vSwitch, Distributed vSwitch or Nexus1000. This is where you get “into” the cloud. The external network is a network where you physically have allocated a vlan and an IP segment. The IP segment can either be public internet ip addresses or private ip addresses. In our case we are using the private subnet “10.10.10.0/24” When you define your External Network you have to define this IP segment gateway and subnet mask. Besides that you define a “static IP pool”. This pool is addresses vCloud director can manage and use for vShield edge devices and virtual machines.

Organisation network: An organisation network is a network only available to the organisation it is deployed to. This network is automatically created in vCloud Director and you don’t need to manually create the portgroup in vSphere. The Organisation network can either be 1) direct connected to an external connected (in this case we use 10.10.10.0/24) 2) routed connected with a vShield edge device (in this case a vShield edge device will have an IP on the external network example: 10.10.10.20 and another ip address on the organisation network – for instanse 192.168.0.1) or 3) no connection to an external network.

vApp network: a vApp network available to only virtual machines in the same vApp. This network is automatically created when defining it. The vApp network can either be 1) routed connected to the organisation network or 2) no connection to organisation network.

If you need more information on vCloud network concepts check out Duncans great two series post on the matter: vcd network post 1 |  vcd network post 2

Fencing in vCloud Director

Option 1:

You can do fencing in vCloud director in two ways. When looking at the GUI it would seem only one. But you can actually do fencing without putting a vApp into “Fence vApp” mode. An example of this. Look at the following two screenshots. I am building a vApp that is connected to my organisation network. That means I am using my organisation IP addresses for all virtual machines in the vApp. (10.10.10.0/24). In the first screenshot I have not selected the “Fence vApp” checkmark. In the second I have selected it.

                  

The first one is direct connected to the organisation network – and in this option I have no way of running with duplicate IP and MAC for my virtual machines. After selecting the “Fence vApp” checkmark you should notice that it changes connection type to “Fenced” and you will see NAT and FIREWALL enabled. In this case we can now copy the vApp without customization and run it serveral times with the same IP and MAC addresses.

One thing to notice about this way of doing fencing is that you can only use the “Fence” button on organisation networks. NOT on vApp networks. This will give a situation where a vShield Edge will be deployed where the internal and external interface has the same IP subnet(10.10.10.0/24), and the edge does proxy-arp and NAT 

This option is probably the first one you would go to because you acutally see the “Fence” option inside vCloud Director. The truth is though, that you can do fencing without ever setting that option. And you would probably do option 2 instead.

Option 2: 

When looking at option1 we see that the vShield edge device is the one making sure we can do the fencing. In vCloud director when we create “vApp” network we can choose to make it “routed” to an organisation network. To do “manually” fencing you would create a vApp network when creating your vApp. This vApp you would connect with a routed connection to the External network. In our case we would get a “vApp” network with IP 192.168.2.0/24 with a vShield Edge Device connected and on the other side of the vShield edge you would have the 10.10.10.0/24 network. 

      

Look at screenshot 2 and 3. This is what happens when you copy a vApp and don’t customize it. The vApp network will be the exact same. The only difference is the external IP address of the vShield Edge device. This means that you can use the external address to get “into” your vApps virtual machine with a simple NAT rule.

Summary

Fencing can be done in two ways. Both use the vShield Edge Device.

Option 1: Use the “Fence” option and use your organisation IP range directly on your fenced virtual machines. (same inside and outside IP range 10.10.10.0/24)

Option 2: Create a vApp network and make it “routed”. In this case you have one internal IP segment192.168.0.0/24 and one external IP segment 10.10.10.0/24)

 

 

 

 

 

 

 

Filed Under: vCloud

Primary Sidebar

Blogroll

  • Hazenet
  • Michael Ryom
  • Perfect Cloud
  • vTerkel

Copyright © 2023 · News Pro on Genesis Framework · WordPress · Log in