Tuesday, March 31, 2015

VCDX Application submitted - time for mock defenses

I have just submitted my VCDX application for June defense in Frimley, UK. I assume all my readers know what VCDX stands for. For those who don't look at VCDX.vmware.com for further details. I don't want to write about VCDX defense process, preparation, etc. because there are lot of other blog posts and resources available on the internet.

I think that VCDX is about continuous lifelong learning at home and practicing in the field. However I believe that learning must be significantly boosted before the defense because in VCDX panel are sitting the most skilled vSphere architects on this planet. Therefore your success probability increases when you are prepared for any question regarding your design.

Preparing together is better. That's the reason I'm looking for other VCDX candidates already submitted VCDX applications and targeting July defense. I would be more then happy to organize study sessions or mock defenses over the webex.

Below are session times best suiting me. However, if you prefer another time just write a comment or send a tweet to @david_pasek and I can arrange another sessions.

All times are in Central European Time (GMT+2). If you want to register send a tweet to @david_pasek or post a comment with date(s) you are planning to attend.
Session time
Location & Topic
Attendees

April 06, Mon 
9pm – 11pm
Location: webex TBD
Topic: TBD
David Pasek (O)
S
April 13, Mon
9pm – 11pm
Location: webex link
Topic: Mock defense
David Pasek (O)
Olivier B (A,P)
S
April 20, Mon
9pm – 11pm
Location: webex link
Topic: Mock defense
David Pasek (O,G)
Olivier B (A,P)
@nickbowienz(A,P)
Shady Ali (A)
Kiran Reid (A)
S
April 27 Mon 
9pm – 11pm
Location: webex link
Topic: Larus's Mock defense
David Pasek (O,P)
Larus Hjartarson(G)
Simon H. (P)
S
May 04 Mon 
9pm – 11pm
Location: webex link
Topic: Simon's Mock defense
David Pasek (O,P)
Larus Hjartarson(P)
Simon H. (G)
S
May 11, Mon
9pm – 11pm
Location: webex link
Topic: David's Mock defense
David Pasek (O,G)
Larus Hjartarson(P)
Simon H. (P)
S
May 18, Mon
9pm – 11pm
Location: webex link
Topic: Larus's Mock defense
David Pasek (O,P)
Larus Hjartarson(G)
Simon H. (P)
S
May 25, Mon
9pm – 11pm
Location: webex link
Topic: Simon's Mock defense
David Pasek (O)
Larus Hjartarson(P)
Simon H. (G)

June 01, Mon
 9pm – 11pm
Location: webex TBD
Topic: TBD







Legend:
S - Session scheduled
(O) - Organizer
(A) - Attendee
(P) - Panelist
(G) - VCDX candidate to be grilled :-)

Posted by at 2 comments:
Labels: ,

Sunday, March 15, 2015

DELL Force10 : mVLT – Ethernet Loop Free Topology Design

Last week I have received following question from one of my reader …
I came to your blog post http://blog.igics.com/2014/05/dell-force10-vlt-virtual-link-trunking.html and I am really happy that you shared this information with us. However I was wondering if you have tested a scenario with 4 S4810 with VLT configured on 2 x 2 and connected together (somewhere called mLAG). How do you continue to add VLT couples to the setup? I would be really happy if you could provide any info regarding such setup.
So let’s deep dive into VLT port-channel between two Force10 VLT Domains also known as mVLT. Please note that VLT can be configured not only between two Force10 VLT domains but also between Force10 VLT domain and other multi chassis port-channel technology like for instance CISCO virtual Port Channel (vPC). However, this blog post is focused to single vendor solution mVLT on DELL S-Series Switches (previously known as Force10 S-Series).

If you are not familiar with DELL Force10 VLT technology read my previous blog post where is VLT described in detail. It is really important to understand VLT before you try to understand mVLT (Multi-domain VLT). By the way mVLT is called eVLT (Enhanced VLT) in Force10 documentation so it might be little bit confusing. Anyway mVLT is nothing else then regular virtual port channel (VLT) between  two VLT domains. Therefore mVLT is quite good term if you ask me.

mVLT Logical Design
mVLT logical design is pretty straight forward. It is required to achieve stretched L2 over two datacenters without any loops. This topology is often called loop free topology and it is depicted on figure below from spanning tree (STP) point of view.


However we would like to have hardware and link redundancy therefore multi chassis port-channel technology (Force10 VLT in our particular case) is used to still have simple loop free topology from spanning tree point of view but with switch unit and physical link redundancy. Force10 mVLT solution is logically depicted on figure below.


Please note, that each single VLT Domain act in spanning tree as a single logical switch.

DELL highly recommends using four links between VLT domains because of higher redundancy and optimal data flow. However, sometimes your are constraint with links between sites. Two links DCI is also supported design but not recommended because there is obviously lower link redundancy and therefore higher probability of communication over VLTi which adds hop and therefore latency. Two links mVLT DCI also known as square design is depicted on figure below. 


Even the topology is loop free and from logical view we have just one switch on each datacenter spanning tree protocol should be enabled and configured just in case of human error or VLT domain failure or split. Rapid Spanning Tree (RSTP) protocol is good enough therefore used later in physical configurations.

mVLT Physical Design and Configuration
Physical design below shows connectivity of four (2x two) Force10 S4810 switches leveraging four links for DCI port-channel (mVLT).


Physical design for just two links DCI is depicted on following schema.


And switch configuration snippets for four links mVLT are listed below for completeness. Two link DCI is just variation of similar configurations so you can simply reuse and slightly change four link configuration.

DCA-SWCORE-A – acts as primary Root Bridge in RSTP in case of loop
!
hostname DCA-SWCORE-A
!
protocol spanning-tree rstp
 no disable
 hello-time 1
 max-age 6
 forward-delay 4
 bridge-priority 4096
!
vlt domain 1
 peer-link port-channel 128
 back-up destination 172.16.201.2
 primary-priority 1
 system-mac mac-address 02:00:00:00:00:01
 unit-id 0
 peer-routing
!
 proxy-gateway lldp
  peer-domain-link port-channel 127
!
interface TenGigabitEthernet 0/46
 no ip address
 mtu 12000
! 
 port-channel-protocol LACP
  port-channel 127 mode active
 dampening 10 100 1000 60
 no shutdown
!
interface TenGigabitEthernet 0/47
 no ip address
 mtu 12000
! 
 port-channel-protocol LACP
  port-channel 127 mode active
 dampening 10 100 1000 60
 no shutdown
!
interface fortyGigE 0/56
 no ip address
 mtu 12000
 no shutdown
!
interface fortyGigE 0/60
 no ip address
 mtu 12000
 no shutdown
!
interface ManagementEthernet 0/0
 ip address 172.16.201.1/24
 no shutdown
!
interface Port-channel 127
 description "mVLT - interconnect link"
 no ip address
 mtu 12000
 switchport
 vlt-peer-lag port-channel 127
 no shutdown
!
interface Port-channel 128
 description "VLTi - interconnect link"
 no ip address
 mtu 12000
 channel-member fortyGigE 0/56,60
 no shutdown
!

DCA-SWCORE-B  – acts as secondary Root Bridge in RSTP in case of loop
!
hostname DCA-SWCORE-B
!
protocol spanning-tree rstp
 no disable
 hello-time 1
 max-age 6
 forward-delay 4
 bridge-priority 8192
!
vlt domain 1
 peer-link port-channel 128
 back-up destination 172.16.201.1
 primary-priority 8192
 system-mac mac-address 02:00:00:00:00:01
 unit-id 1
 peer-routing
!
 proxy-gateway lldp
  peer-domain-link port-channel 127
!
interface TenGigabitEthernet 0/46
 no ip address
 mtu 12000
! 
 port-channel-protocol LACP
  port-channel 127 mode active
 dampening 10 100 1000 60
 no shutdown
!
interface TenGigabitEthernet 0/47
 no ip address
 mtu 12000
! 
 port-channel-protocol LACP
  port-channel 127 mode active
 dampening 10 100 1000 60
 no shutdown
!
interface fortyGigE 0/56
 no ip address
 mtu 12000
 no shutdown
!
interface fortyGigE 0/60
 no ip address
 mtu 12000
 no shutdown
!
interface ManagementEthernet 0/0
 ip address 172.16.201.2/24
 no shutdown
!
interface Port-channel 127
 description "mVLT - interconnect link"
 no ip address
 mtu 12000
 switchport
 vlt-peer-lag port-channel 127
 no shutdown
!
interface Port-channel 128
 description "VLTi - interconnect link"
 no ip address
 mtu 12000
 channel-member fortyGigE 0/56,60
 no shutdown
!
DCB-SWCORE-A – acts as tertiary Root Bridge in RSTP in case of loop
!
hostname DCB-SWCORE-A
!
protocol spanning-tree rstp
 no disable
 hello-time 1
 max-age 6
 forward-delay 4
 bridge-priority 12288
!
vlt domain 2
 peer-link port-channel 128
 back-up destination 172.16.202.2
 primary-priority 1
 system-mac mac-address 02:00:00:00:00:02
 unit-id 0
 peer-routing
!
 proxy-gateway lldp
  peer-domain-link port-channel 127
!
interface TenGigabitEthernet 0/46
 no ip address
 mtu 12000
! 
 port-channel-protocol LACP
  port-channel 127 mode active
 dampening 10 100 1000 60
 no shutdown
!
interface TenGigabitEthernet 0/47
 no ip address
 mtu 12000
! 
 port-channel-protocol LACP
  port-channel 127 mode active
 dampening 10 100 1000 60
 no shutdown
!
interface fortyGigE 0/56
 no ip address
 mtu 12000
 no shutdown
!
interface fortyGigE 0/60
 no ip address
 mtu 12000
 no shutdown
!
interface ManagementEthernet 0/0
 ip address 172.16.202.1/24
 no shutdown
!
interface Port-channel 127
 description "mVLT - interconnect link"
 no ip address
 mtu 12000
 switchport
 vlt-peer-lag port-channel 127
 no shutdown
!
interface Port-channel 128
 description "VLTi - interconnect link"
 no ip address
 mtu 12000
 channel-member fortyGigE 0/56,60
 no shutdown
!

DCB-SWCORE-B – acts as quaternary Root Bridge in RSTP in case of loop
!
hostname DCB-SWCORE-B
!
protocol spanning-tree rstp
 no disable
 hello-time 1
 max-age 6
 forward-delay 4
 bridge-priority 16384
!
vlt domain 2
 peer-link port-channel 128
 back-up destination 172.16.202.1
 primary-priority 8192
 system-mac mac-address 02:00:00:00:00:02
 unit-id 1
 peer-routing
!
 proxy-gateway lldp
  peer-domain-link port-channel 127
!
interface TenGigabitEthernet 0/46
 no ip address
 mtu 12000
! 
 port-channel-protocol LACP
  port-channel 127 mode active
 dampening 10 100 1000 60
 no shutdown
!
interface TenGigabitEthernet 0/47
 no ip address
 mtu 12000
! 
 port-channel-protocol LACP
  port-channel 127 mode active
 dampening 10 100 1000 60
 no shutdown
!
interface fortyGigE 0/56
 no ip address
 mtu 12000
 no shutdown
!
interface fortyGigE 0/60
 no ip address
 mtu 12000
 no shutdown
!
interface ManagementEthernet 0/0
 ip address 172.16.202.2/24
 no shutdown
!
interface Port-channel 127
 description "mVLT - interconnect link"
 no ip address
 mtu 12000
 switchport
 vlt-peer-lag port-channel 127
 no shutdown
!
interface Port-channel 128
 description "VLTi - interconnect link"
 no ip address
 mtu 12000
 channel-member fortyGigE 0/56,60
 no shutdown
!

Conclusion

Force10 mVLT is great technology for loop free L2 network topology. It can be leveraged for local loop free topologies inside single datacenter or as L2 extension between datacenters. However our networks are usually built to support IP traffic therefore L3 considerations has to be addressed as well. Just think about default IP gateway behavior and potential DCI potential trombone.  That’s where other VLT features peer-routing and proxy-gateway come in to play and mitigate DCI trombone issue. You can see these technologies configured in VLT configurations above. But that’s another topic for another blog post.

To be absolutely honest I personally don't recommend L2 interconnects between datacenters without any good justification. I strongly recommend L3 datacenter interconnects and when stretched L2 is needed then some network overlay technology can be leveraged. L3 will guarantee independent availability zones and splitting L2 failure domain. But on the other hand such network overlay needs some other bits and pieces which in some cases increase complexity and cost. Therefore mVLT can be seriously considered for cost effective datacenter L2 extensions.  That's a typical "it depends" scenario where these two design decision options has to be compared and final decision clearly justified.   

If you want to know more about these technologies or use cases just ask and we can go deeper or broader. And as always any feedback and/or comment is highly appreciated.
Posted by at 19 comments:
Labels: , ,

Saturday, March 14, 2015

VMware Virtual SAN Diagnostics and Troubleshooting Reference Manual

Well known VMware's storage evangelist Cormac Hogan wrote and published another VMware VSAN related document. Well, it is the book having almost 300 pages. And the nice thing is that this document/book/manual is publicly available for free.

Snip from document Introduction Chapter ...
VMware’s Virtual SAN is designed to be simple: simple to configure, and simple to operate. This simplicity masks a sophisticated and powerful storage product. The purpose of this document is to fully illustrate how Virtual SAN works behind the scenes: whether this is needed in the context of problem solving, or just to more fully understand its inner workings.
Here is the link ... http://www.vmware.com/files/pdf/products/vsan/VSAN-Troubleshooting-Reference-Manual.pdf

So if you want to know VSAN details for diagnosis and troubleshooting you have to read it.
Posted by at No comments:
Labels: ,

Thursday, February 19, 2015

SQL commands for information of vCenter Server Database usage

Let's assume we have simple installation of vCenter Server database leveraging MS SQL Express and we want to know how much database space is currently used. The simplest way is to use existing sqlcmd program. Connect to MS Windows server where vCenter is installed. Open command prompt or PowerShell and use following SQL commands ...

sqlcmd -E -Slocalhost\VIM_SQLEXP
1>use VIM_VCDB
2> go
Changed database context to 'VIM_VCDB'.
1> sp_spaceused
2> go
database_name
         database_size      unallocated space
---------------------------------------------------------------------------------------- ------------------ ------------------
VIM_VCDB
         244.94 MB          0.93 MB
reserved           data               index_size         unused
------------------ ------------------ ------------------ ------------------
234824 KB          152800 KB          63200 KB           18824 KB

1>

 There you can see that VIM_VCDB database size is 244.94 MB.

Note: In this particular environment I have just two ESX hosts with eight virtual machines.
Posted by at No comments:
Labels: , ,

Wednesday, February 11, 2015

Dell networking optics and cables connectivity guide

DELL Product Management has just released eternally available guide fro DELL networking optics and cables connectivity. It is very valuable for me so I believe it will be helpful for broader IT infrastructure community.

I have published the document on Slideshare at http://www.slideshare.net/davidpasek/dell-networking-optics-and-cables-connectivity-guide


Posted by at No comments:
Labels: , ,

Monday, February 09, 2015

How to change VM Network using linux command line?

Yesterday I read this Cormac's blog post and one of his reader (Philip Orleans) posted following comment ...
Just a personal favor, can you ask from the Vmware managers to enforce parity of functionality between management command line tools in Linux and Windows? It is a shame that the Linux tools are so far behind Power Shell.
Very well known PowerCLI scripting guru and VMware's Product Manager for CLIs Alan Renouf answered very quickly ...
Philip, thanks for the comment on Cormacs site, I am the Product Manager for CLIs at VMware and I can tell you we hear you loud and clear and we have a plans to bring the linux side of the house up to speed at some point in the future.

By the way, that's exactly what I really like on VMware's community and efficient communication with big corporation what VMware already is ...

Philip point out to one practical example where PowerCLI is the the only way how to automate VM network reassign to different network. I absolutely agree that PowerCLI is much simpler and feature rich scripting platform than linux alternatives. That's exactly what linux/*nix oriented vSphere administrators would like to see from VMware. However I don't agree it is not possible to achieve your goal.

Below is the question Philip raised ...
I am very happy that somebody is listening. A few weeks ago, here, I posted a question about how to change network for a VM using only Linux command line tools, and some idiot mocked me, told me to study, when in fact, there is no way, as far as I researched. This can be achieved only with Powershell. Unfortunately, one of my customers is so paranoid, that I am not allowed on premises with a Windows machine. If I did try, I would have to flee to Moscow.

In the history, the first scripting toolkit was targeted to linux administrators. It was Perl SDK nowadays known af vCLI. I used to use Perl SDK to develop several automation projects in the past. I even wrote something like VMware's "Site Recovery Manager" to achieve automated disaster recovery fail over, test, and fail back. To achieve DR testing in isolated network bubble you need to change VM networks, right? In that times I've developed perl function to do it. Based on Philip's question I've realized that it can be still valuable to some folks even the script was developed back in 2009. I spent just two hours with some quick re-factoring and below is single linux command which can be used to change virtual network on particular VM for particular VM Network Adapter.

/usr/lib/vmware-vcli/apps/vm/vmchnet.pl --server 10.10.4.70 --username administrator --vmname test-vm --vnic 2 --network my-test-network
Ok, it's kind of a joke :-) There is single command above but you need the script below to achieve it ...

 #!/usr/bin/perl -w  
 ###############################################################################  
 # Author: David Pasek  
 # Email: david.pasek[at]gmail.com  
 # Blog: http://blog.igics.com  
 #  
 # Created: 01/27/2009  
 # Updated: 02/09/2015  
 #  
 # Abstract:  
 # Reconfigure particular VM Network iAdapter to be in particular network label  
 # in VMware standard virtual Switch. Network label is also known as PortGroup.  
 #  
 # Script requires VMware's PERL SDK (aka vCLI)therefore it must be placed  
 # in apropriate directory tree location to work correctly.  
 # Optimal location is at /usr/lib/vmware-vcli/apps/vm  
 #  
 # Disclaimer: Use this script at your own risk. Author is not responsible  
 # for any impacts of using this script.  
 ###############################################################################  
 use strict;  
 use warnings;  
 use FindBin;  
 use lib "$FindBin::Bin/../";  
 use VMware::VIRuntime;  
 use XML::LibXML;  
 use AppUtil::VMUtil;  
 use AppUtil::XMLInputUtil;  
 use Data::Dumper;  
 $Util::script_version = "1.0";  
 my %opts = (  
   'vmname' => {  
    type => "=s",  
    help => "Name of virtual machine",  
    required => 1,  
   },  
   'vnic' => {  
    type => "=i",  
    help => "VM Network Adapter number - 1, 2, ...",  
    required => 1,  
   },  
   'network' => {  
    type => "=s",  
    help => "Name of new virtual network",  
    required => 1,  
   },  
 );  
 Opts::add_options(%opts);  
 Opts::parse();  
 Opts::validate(\&validate);  
 # connect to the server  
 Util::connect();  
 my $vmname = Opts::get_option('vmname');  
 my $vnic = Opts::get_option('vnic');  
 my $network = Opts::get_option('network');  
 &vm_change_net('vmname' => $vmname,  
         'vnic' => $vnic,  
         'network' => $network);  
 Util::disconnect();  
 exit;  
 sub vm_change_net {  
  my %params = @_;  
  my $vmname =$params{vmname};  
  my $vnic =$params{vnic};  
  my $network = $params{network};  
  my $vm_view;  
  $vm_view = Vim::find_entity_view(view_type => 'VirtualMachine',  
        filter => {'name' => $vmname });  
  if(!defined $vm_view) {  
   print "Cannot find VM: $vmname\n";  
   return(255);  
  }  
  my $devices = $vm_view->config->hardware->device;  
  foreach my $dev (@$devices) { # DEVICE  
   my $device_type = ref($dev);  
   my $device_name = $dev->deviceInfo->label;  
   my $device_key = $dev->key;  
   #print "Device type: $device_type\n";  
   #print "Device name: $device_name\n";  
   #print "Device device key: $device_key\n";  
   if ( $device_name eq "Network adapter $vnic") { # NETWORK ADAPTER  
    print "Device type: $device_type\n";  
    print "Device name: $device_name\n";  
    print "Device key: $device_key\n";  
    # Change network information  
    my $changed_device;  
    my $backing_info = VirtualEthernetCardNetworkBackingInfo->new( deviceName => $network );  
    if ($device_type eq "VirtualPCNet32") {  
     $changed_device = VirtualPCNet32->new(key => $device_key,  
                        backing => $backing_info);  
    }  
    if ($device_type eq "VirtualE1000") {  
     $changed_device = VirtualE1000->new(key => $device_key,  
                       backing => $backing_info);  
    }  
    if ($device_type eq "VirtualVmxnet3") {  
     $changed_device = VirtualVmxnet3->new(key => $device_key,  
                        backing => $backing_info);  
    }  
    my $config_spec_operation;  
    $config_spec_operation = VirtualDeviceConfigSpecOperation->new('edit');  
    my $device_spec =  
    VirtualDeviceConfigSpec->new(operation => $config_spec_operation,  
                   device => $changed_device);  
    my @device_config_specs = ();  
    push(@device_config_specs, $device_spec);  
    my $vmspec = VirtualMachineConfigSpec->new(deviceChange => \@device_config_specs);  
    # RECONFIGURE VM  
    eval {  
     print "Changing Network Adapter $vnic in virtual machine $vmname\n";  
     $vm_view->ReconfigVM( spec => $vmspec );  
     print "Success\n";  
    };  
    if ($@) {  
     print "Reconfiguration failed:\n";  
     print($@);  
    }  
   } # NETWORK ADAPTER - END  
  } # DEVICES - END  
  return;  
 }  
 sub validate {  
   my $valid = 1;  
  return $valid;  
 }

Script above is limited to standard VMware virtual switch. If you are looking for similar script dealing with VMware distribute virtual switch look here. There is a link to script developed by Javier Viola.

As you can see PERL SDK is not easy for normal vSphere admins and when there are no precooked vCLI commands it is almost useless for someone who doesn't have some programming background. PowerCLI is absolutely another story and as VMware is moving out of Microsoft technologies I would expect some PowerCLI alternative in PERL or Python and based on Alan's comment I believe VMware is already working on some alternative. I'm really looking forward for linux alternative and I'm not alone.

By the way, nowadays there is another possibility to achieve the goal without MS Windows systems. vCenter Orchestrator (or vRealize Orchestrator) however it is another story.

Hope this helps to someone.
 


Posted by at 3 comments:
Labels: , ,

Monday, February 02, 2015

vSphere 6 Announcements

Bellow is a brief transcript of VMware vSphere 6 related announcements. The list of new features may not be complete because I have noted just features important and interesting for me as vSphere Architect designing datacenter infrastructures.

Disclaimer: I'm not responsible for any errors and inaccuracies in the transcript bellow.

vSphere 6 New Features

  • vSphere HA (High Availability) Cluster supports up to 64 hosts
  • vSphere FT (Fault Tolerance) supports up to 4 vCPUs
  • VM supports up to 128 vCPU/4TB vRAM
  • vMotion across vCenters
  • Long Distance vMotion (should work up to 100 ms of round trip time)
  • VVOLs released
  • NFS 4.1 support multipathing and Kerberos Authentication
  • Up to 2x increase in concurrent vCenter operations
  • 10x faster vCenter operations
  • vCenter Server Appliance supports 1,000 ESXi hosts and 10,000 VMs
  • vSphere WEB Client 5x faster
  • Platform Service Controller (PSC) introduces. SSO and SSL Certification are sub components of PSC. 

VSAN 6 New Features

  • All flash architecture supported
  • Limits increased: 64 hosts, 2000 VMs per host, 32 snapshots per VM, vDisk up to 62 TB
  • Rack Awareness (Fault Domains)
  • Health Checks

Cloud New Features

  • VMware Integrated OpenStack (VIO) - very tightly integrated vSphere 6 with Open Stack Cloud Management layer
  • Open Stack fully supported by VMware and included in support fees

You can check out VMware Online Announcement recording at http://bcove.me/m0amsphc

List of other What's new blog posts I found very useful ...

Other vExpert's vSphere 6 related blog posts ...

vExperts participating in vSphere beta program wrote lot of blog posts about various vSphere 6 topics. All these blog posts are aggregated at 

Warning: I strongly believe that all bloggers are doing great job but don't trust everything written in the internet and validate any information with VMware official documentation. 

 Please, let me know if I missed or misunderstood something important.
Posted by at 1 comment:
Labels: ,
Subscribe to: Posts (Atom)