Niran (@niranec on Twitter) is a Staff SE Specialist in VMware’s Network and Security BU, specializing in NSX and applications.
With over 15 years of experience in IT Engineering, architecture and sales roles.
The technical expertise Niran acquired includes design, technical selling and evangelizing of virtualization, Networking, Storage, performance, Cloud (CNA and Cloud management) and BC/DR solutions.
In his current position at VMware Niran devotes his time in helping Enterprise and global customers in their journey to digital transformation with Developer Ready Infrastructure, focusing on NSX and Pivotal Cloud Foundry Integration.
In his previous positions at VMware Niran was the main SME at VMware for Microsoft SQL Server virtualization and the author of the official best practices guides it, and also a Cloud and Performance specialist.
Niran is a frequent speaker at industry events and conferences including VMworld, VMUGs, SQL Saturdays and more. He is also part of the CTO Ambassador Program at VMware.
Microsoft SQL Server is the most virtualized enterprise mission critical application today. In recent years it has become a mainstream effort among VMware customers to virtualize critical databases to allow better agility and scale while increasing availability and operational efficiency.
The official best practices guide for virtualizing SQL Server is now updated with information regarding vSphere 6.5 and some new lessons learned in the past year.
A big Thank you! is due to:
Allan Hirt (Twitter @SQLHA) for keeping me honest on SQL Server nomenclature
David Klee (Twitter @Kleegeek) for his help reviewing this paper
Deji Akomolafe (Twitter @dejify) for his expertise and contribution
In this blog post we are showcasing the ability to stretch an Oracle RAC solution in an Extended Oracle RAC deployment between multi-datacenter and using VMware NSX for L2 Adjacency.
With Extended Oracle RAC , both Storage and Network virtualization needs to be deployed to provided high availability, workload Mobility, workload balancing and effective Site Maintenance between sites. Continue reading →
Choosing the right availability configuration for your SQL Server on vSphere can be a bit confusing as there are more than a few options to choose from, questions such as: Should I use vSphere HA if i’m using AlwaysOn? What are the implications of running different availability configurations on vSphere, and what are the best practices?
This very popular guide called “Microsoft SQL Server on VMware vSphere Availability and Recovery Options” which outlines the availability options and best practices for SQL Server on vSphere and tries to answer these question, is now updated with the latest information.
VMware NSX is a software defined solution that brings the power of virtualization to network and security.
There are many great papers about NSX in general: for example here & here and many others, the purpose of this demo is not to dive into everything that NSX does, Instead I have focused on one capability in particular and that is the intelligent grouping of NSX Service Composer with the Distributed Firewall (DFW) and how to utilize it to make life easier for SQL DBAs and security admins, its doesn’t have to be only SQL Server, it can be any other database or application for that matter but for this demo I am focusing on SQL Server.
First, a bit of background: The NSX Service Composer allows us to create groups called “Security groups”. These Security groups can have a dynamic membership criteria that can be based on multiple factors: It can be part of the computer name of a VM, its guest OS name, the VM name, AD membership or a tag (tags are especially cool as they can be set automatically by 3rd party tools like antivirus and IPSs, but that is for a different demo)
These Security groups are than placed inside the Distributed Firewall (DFW) rules which allows us to manage thousands of entities with just a few rules and without the need to add these entities to the Security Group manually.
In the demo I have created an environment that is set with 0 trust policy, that means that everything is secured and every packet between the VMs is inspected, the inspection is done on the VMs vNIC level in an east-west micro segmentation way. That means that if a certain traffic is not defined in the DFW it is not allowed to go through.
This is something that wasn’t really possible to do before NSX
Our production app database is an SQL database and in the demo the DBA wants to hot-clone it aside for testing purposes, but obviously the cloned SQL Server needs to have some network traffic allowed to pass to it, yet it needs to be secured from everything else.
Instead of having the traditional testing FW zone with its own physical servers, I created the rules that apply to a test DBs in the DFW, created a dynamic membership Security Group, and nested that group in the rules. Now, any database server that I will clone which corresponds to the criteria will be automatically placed in the rules. What’s really nice about this is that no traffic is going northbound to the perimeter FW because the packet inspection is done on the vNIC of the VMs (and only relevant rules to it are set on it) , no additional calls to security admins to configure the FW are needed after the first configuration has been made. This is a huge time saver , much more efficient in terms of resources (physical servers are now shared between zones) and a much more secure environment than having only a perimeter FW.
Microsoft SQL server is the most virtualized enterprise mission critical application today. In recent years it has become a mainstream effort among VMware customers to virtualize critical databases to allow better agility and scale while increasing availability and operational efficiency.
This guide, now named “Architecting Microsoft SQL Server on VMware vSphere – Best Practices Guide” to reflect its focus on architecture and configurations of vSphere as well as SQL server for maximizing the benefits of virtualizing SQL server, is aimed at providing VMware customers and partners guidance on how to achieve best performance and efficiency with the latest versions of Microsoft SQL server and VMware vSphere.
In this guide there are also references to other VMware and third-party documents which we encourage the reader to consult for better understanding of the topics discussed.
Recently, I have been asked this question: should we enable Storage I/O control on datastores used by our production databases considering it could prevent my VMs from consuming all the resources they need? The answer is yes, SIOC will not harm your performance, actually it can save you from a very bad day in IT land, and it’s all about the threshold.
Before I dive deeper into that a bit of background:
Storage I/O control is a technology which provides I/O prioritization for VMDKs that reside on a shared datastore, the VMDKs can reside on different hosts but have to be managed by the same vCenter. This is to contrast with adaptive queuing which is an ESXi technology. Anyway, back to SIOC, when a latency threshold is crossed for a shared datastore Storage I/O control will kick in and will start prioritizing access to that datastore based on the proportional shares mechanism, the outcome will be that VMs with higher shares will get more throughput (IOPS) in lower latency than VMs with lower shares. By default all VMs have the same amount of shares and a fair access to the datastore, in that case SIOC will protect from the “noisy neighbor” issue from happening making sure that no one VM monopolizes access to that datastore. Continue reading →
“For customers using Intel’s hyper-threading technology to split a single, physical core into two separate threads of power, there are some additional factors that should be kept in mind when licensing individual VMs using the Per Core Model”
This states that there arespecial considerations for licensing virtualized SQL servers on a per-core model when Hyper-threadingis enabled on the hypervisor host.
What is the per core model, you ask?
The per core model is when licensing the virtual CPUs of a virtual SQL server rather than the physical CPUs on the hyper-visor server. As stated in the doc: “Per Core Licensing Model: Purchase a core license for each virtual core (or virtual processor/virtual CPU/virtual thread) allocated to the VM, subject to a four core license minimum per VM).” Continue reading →
Anyone that virtualized Exchange server in recent years had stumbled into this conundrum: should I disable Hyperthreading on the physical server or not?
The main cause of this confusion is conflicting recommendations coming from Microsoft and VMware on the subject, I am happy to say that this debate is finally over. As we at VMware have been saying all along, there is no need to disable Hyperthreading when virtualizing Exchange server; that recommendation was suitable only for physical servers and is irrelevant for virtual machines. Continue reading →