vFrank

Essense of virtualization

vSphere

vCenter er nede, hvad gør du?

by 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

Command line update ESXi 6

by Leave a Comment

Updating a standalone ESXi host is a very easy process with the built-in esxcli command. Here is the high-level process

NOTE: All ESXi embedded patches are cumulative. It means it contains ALL patches. You only need to download the latest version and can safely ignore the rest

  1. Download the latest ESXi Embedded Installable from here: http://www.vmware.com/patchmgr/findPatch.portal
  2. Upload the downloaded bundle do a datastore accessible by your ESXi host. I use the built-in datastore browser
  3. Put the ESXi host in maintenance mode
  4. Login with SSH to the ESXi host
  5. Use the following command to update: esxcli software vib update -d /vmfs/volumes/local/ESXi600-201610001.zip
  6. Reboot the ESXi host
  7. Exit maintenance mode

Here are some pictures of the process:

Picture 1: ESXi version 3620759 before the update

screenshot-2016-10-30-20-49-41

 

 

 

 

 

 

 

Picture 2: Use the datastore browser to upload the downloaded ESXi bundle to a datastore

screenshot-2016-10-30-20-52-04

 

 

 

 

 

 

Picture 3: esxcli software vib update

screenshot-2016-10-30-20-57-53

 

 

 

 

 

 

Picture 4: After reboot ESXi updated to 4510822

screenshot-2016-10-30-21-01-07

 

Running PernixData FVP in Monitor Mode

by 2 Comments

Back in March Frank Denneman wrote the following article about running PernixData FVP in Monitor Mode. I suggest that you read it before you read this post.

The great thing about monitor mode is that without the use of Flash or RAM for acceleration you will get a clear picture of how your storage array is performing. With the information gathered from this exercise you will know what to do next. Monitor mode will either let you choose to continue the POC with PernixData and start accelerating virtual machines. Or you may learn that your storage array got the performance you need. No matter the outcome you as administrator will know more about your environment and have learned about the IOPS profiles from your virtual machines.

I often get the question “What graph should I look at in monitor mode?” 

A good place to start is the Summary graph on a Cluster level. This will show you information for all virtual machines latency running in that cluster. To start you should only add the two counters

– Datastore Read
– Datastore Write

Screenshot 2015-01-05 17.10.56

By looking at this graph you will get a quick summary of Read & Write latency the virtual machines are experiencing in your environment. At one data point in this graph we see a Read Latency at 105 ms. and Write latency of 30 ms.

When you see this there is no doubt that PernixData FVP will be able to help your virtual machines getting predictable low latency performance.

The next step is to try to accelerate your virtual machines. PernixData can use SSD, PCI-E flash or RAM for acceleration. When you choose you have two factors to think about

1. Performance of the acceleration media
2. Capacity

You want a good SSD/PCI-E flash device that gives you predictable low latency for read and write IOPS but you also want a drive with the right capacity. If the capacity is low you will not get the hit-ratio you are looking for. Capacity is a huge advantage for SSD/PCI-E over RAM. RAM is faster – but I would not sacrifice that capacity from a good performing SSD over RAM with lower capacity.

If we move on and start to accelerate with RAM/SSD/PCI-E you can then use the graphs again to show the difference.

This picture shows the Datastore Write Latency and Write latency. Write equals VM Observed Write. So that latency is what the VM is experiencing. At the data point highlighted we have a datastore latency of 30 ms. but the VM is experiencing 1.39 ms because of local flash acceleration!

Screenshot 2015-01-05 17.10.20

 

The next picture focuses on Read latency. The counters selected are Datastore Read & Read. The highlighted data point shows datastor latency at 105 ms but the VM is experiencing 5 ms because of local acceleration.

Screenshot 2015-01-05 17.10.03

 

Monitor Mode is a strong tool to use during a PernixData FVP POC. It is not necessary to use it though. If you have flash/RAM available from the get-go you can still use the graphs to show what is going on. The graphs are right inside the vSphere Client or vSphere Web Client.

Once customers get FVP in their environment they don’t use the vCenter Performance graphs for storage performance anymore. They go straight to PernixData and uses them instead.

If you are interested in figuring out what storage Read & Write latency you are experiencing today. Then go and request a free trial version of PernixData FVP software here

 

PernixData FVP 1.5 Beta Available

by Leave a Comment

Good news, we just released our Beta program for the upcoming FVP 1.5 release. You can apply for the Beta Program here:

https://beta.pernixdata.com/

Version 1.5 adds support for vSphere 5.5. Full support for the vSphere Web Client is available. If you are still running on vSphere 5.0 or 5.1 you will still use the vSphere Client C# client.

If you want to find out what PernixData is all about, please register for the beta and provide feedback.

VMware VCA Certification 50% Discount Voucher

by Leave a Comment

VMware is still pushing their adoption of the VCA Certifications. You can use the voucher below to get 50% discount. The code will be valid until January 31st.

Voucher: VMRT6B404C7B

You have three VCA Certifications to choose from. The voucher is valid for all three.

VCA-Cloud (Cloud) sign up: http://mylearn.vmware.com/quiz.cfm?item=47439
VCA-DCV (Datacenter) sign up: http://mylearn.vmware.com/quiz.cfm?item=47428
VCA-WM (Workforce Mobility) sign up: http://mylearn.vmware.com/quiz.cfm?item=47438

The VCA Certification can be taken online from anywhere. All you need is internet and a browser. 

How To Enable Traffic Filtering on Distributed Switch in vSphere 5.5

by 2 Comments

A cool new feature on a Distributed Switch in vSphere 5.5  is the ability filter and tag traffic on a Port Group level. This capability is also referred to as access control lists (ACLs), and it is used to provide port-level security. You can create rules of the following qualifiers:

  • MAC Source Address and Destination Address qualifiers
  • System traffic qualifiers – vSphere vMotion, vSphere management, vSphere FT, etc.
  • IP qualifiers – Protocol type, IP SA, IP DA, and port number

When a Package has been classified you can choose to either filter or tag the packets. It is very simple to implement this feature.

Step 1: Create a new vSphere 5.5 Distributed Switch or upgrade an existing. Your ESXi hosts need to be running 5.5 to be able to participate in a 5.5 dvSwitch.

Step 2: Create a port group or go to an existing.

Step 3: Right click the port group and “edit settings” – then go to “Traffic filtering and marking” 

trafficfiterdrop

 

Step 4: Enable the feature. Then create what ever rule you feel like. In my environment I created a rule to drop ICMP packages with a destination of 192.168.2.10 (my DNS server).

trafficfilterdrop2

 

 

After enabling the rule my virtual machine immediately stopped getting ICMP replies.

trafficfilterdrop3

vSphere 5.5 Ready For Download

by Leave a Comment

Good news, I was just browsing the VMware website and I saw that vSphere 5.5 is available for download. I have been part of the beta since early this year and there are so many features I have been looking forward to. Just to name a few.

  • Much improved vCenter Web Client
  • vFlash – Put local SSD/Flash in your ESXi servers and cache most reads to offload your storage array
  • Improved Single Sign On (SSO) Server
  • Support for 62TB .vmdk files

You can read about what else is new here

Head over to the VMware website and start your download. Personally I can’t wait to start working with this version!

vCenter: Cannot complete login due to an incorrect user name or password

by 5 Comments

After upgrading to vSphere 5.1 or installing from scratch you may be in a situation where you cannot authenticate with your vCenter Server when using a domain user.

When you try to log in from the vSphere client you get the following error: Cannot complete login due to an incorrect user name or password 

When you try to log in from the the vSphere Web Client you get the following error: Provided credentials are not valid

SSO1   

SSO2

 

Prior to vSphere 5.1 and the Single Sign On Server SSO you were able to login directly with your domain user without supplying the domain name. 

There are two solutions to the problem.

Solution 1:

When logging in with your domain account add the domain to the user name. You can do this by either writing: DOMAIN\USERNAME or USERNAME@DOMAIN the result will be the same. 

Perhaps you don’t feel this is the right solution for you. You may only have one domain so why should you always write the domain in the log in box. If this is the case see solution 2.

Solution 2:

What you are able to do with SSO and vSphere 5.1 is to add your DOMAIN to the default domain list. you can only accomplish this from the vSphere Web Client. What you need to do is log in to with the user name admin@system-domain and the password defined for this user during installation. Then you go to “Home” – “Administration” – “Single sign-on and discovery” – Configuration. In the identity source window you select your domain and press the “add to default domains” button. If your domain is not present, then you need to add it. You can also add multiple other domains. After adding the domain to the list you then make sure that it is on top of the list in the “Default domains” window. And at the end you press the “Save” button.

 SSO3

By doing this you should now be able to log in without supplying your domain name in the vSphere Client or vSphere Web Client.

vSwitch Load Balancing Policies Best Practises

by 8 Comments

It is important to set the right load balancing policy on your standard or distributed vSwitch. In this article I will talk about how each policy work and give my general recommendation. 

In vSphere we have the following policies to choose from:

  • Route based on originating virtual port ID
  • Route based on IP hash
  • Route based on source MAC hash
  • Use Explicit failover order
  • Route based on physical NIC load (Distributed Switch only)

The originating virtual port ID is the default policy and there is a good reason for that. This policy does not require any special physical switch configuration. In fact you can use all policies except the one based on IP hash without configuring your physical switches with cisco etherchannels or hp trunks. The IP hash policy differs in the way that it let a virtual machine spread its traffic over two or more different vmnic’s (physical network adapter). Because of this the MAC address of the virtual machine will appear on multiple physical switch ports simultaneously. This is why it is required to use ether-channel or trunk the links. 

Lets take an example. We have a virtual switch with a port group. We have 4 virtual machines connected to the port group and 3 physical NICS connected to the virtual switch.

vswitch

Route based on originating virtual port ID works kind of like round robin. VM-A will use vmnic1, VM-B will use vmnic-2, VM-C will use vmnic-3 and VM-D will use vmnic1. The virtual machines are just balanced over the physical available NICS. The virtual machines will have its network running on the designated physical NIC and only that NIC. Of course if we have a failure it will fail over to a different vmnic. 

The good about this configuration is that it is easy to configure. It requires not special physical switch configuration.  The bad is that VM-A and VM-D how are both utilizing the same vmnic could be the two most network intensive virtual machines and they compete for bandwidth while VM-B and VM-C does nothing on their respective vmnics.

Route based on IP hash requires physical switch configuration. (Ether-channel). In this configuration the traffic flows according to the source IP and destination IP. In this case if VM-A is communicating with three different IP’s (clients, other servers etc.) the traffic can use all available vmnic’s. If the VM-B is only communicating with one destination the traffic will not be shared.

Route based on phyiscal NIC load is a newer addition. It quite similar to virtual port ID. But with the addition that it actually looks at the physical NIC load! This means that if VM-A and VM-B both are using a lot of bandwidth on the same physical NIC one of the will be moved to another! If you are running the originating virtual port ID policy on a distributed switch you should change to physical nic load right away.

There are a lof of information out there on this subject. This was just a brief introduction.