The challenge being that cluster services, like the vSphere Distributed Resource Scheduler (DRS), depend on vCenter Server availability for its configuration and operation. And while there’s ways to increase availability for vCenter Server, think about vSphere High Availability (HA) and vCenter Server High Availability (VCHA), its dependency is not ideal. Also, when thinking about vCenter Server scalability in large on-prem and public clouds, we need a better solution to support clustering services. That’s why vCLS is introduced. In the first release, a subset of DRS capabilities is already using the new vCLS feature.

Basic Architecture
The basic architecture for the vCLS control plane consists of maximum 3 virtual machines (VM), also referred to as system or agent VMs which are placed on separate hosts in a cluster. These are lightweight agent VMs that form a cluster quorum. On smaller clusters with less than 3 hosts, the number of agent VMs is equal to the numbers of ESXi hosts. The agent VMs are managed by vSphere Cluster Services. Users are not expected to maintain the lifecycle or state for the agent VMs, they should not be treated like the typical workload VMs.

Cluster Service Health
The agent VMs that form the cluster quorum state, are self correcting. This means that when the agent VMs are not available, vCLS will try to instantiate or power-on the VMs automatically.

There are 3 health states for the cluster services:

Healthy – The vCLS health is green when at least 1 agent VM is running in the cluster. To maintain agent VM availability, there’s a cluster quorum of 3 agent VMs deployed.
Degraded – This is a transient state when at least 1 of the agent VMs is not available but DRS has not skipped it’s logic due to the unavailability of agent VMs. The cluster could be in this state when either vCLS VMs are being re-deployed or getting powered-on after some impact to the running VMs.
Unhealthy – A vCLS unhealthy state happens when a next run of the DRS logic (workload placement or balancing operation) skips due to the vCLS control-plane not being available (at least 1 agent VM).
Agent VM Resources
The vCLS agent VMs are lightweight, meaning that resource consumption is kept to a minimum. vCLS automatically creates a max of 3 agent VMs per cluster in an existing deployment when vCenter Server is upgraded to vSphere 7 update 1. In a greenfield scenario, they are created when ESXi hosts are added to a new cluster. If no shared storage is available, the agent VMs are placed on local storage. If a cluster is formed before shared storage is configured on the ESXi hosts, as would be the case when using vSAN, it is strongly recommended to move the vCLS agent VMs to shared storage after.

The agent VMs run a customized Photon OS. The resource specification per agent VM is listed in the following table:

Memory 128 MB
Memory reservation 100 MB
Swap Size 256 MB
vCPU 1
vCPU reservation 100 MHz
Disk 2 GB
Ethernet Adapter –
Guest VMDK Size ~245 MB
Storage Space ~480 MB

The 2 GB virtual disk is thin provisioned. Also, there’s no networking involved, so there’s no network adapter configured. The agent VMs are not shown in the Hosts and Clusters overview in the vSphere Client. The VMs and Templates view now contains a new folder, vCLS, that contains all vCLS agent VMs. With multiple clusters, all vCLS agent VMs will show, numbered consecutively.

The vSphere Client contains messages and notes to show information about the vCLS agent VMs, also stating that the power state and resources of these VMs is handled by the vCLS.

Operations
As stated before, the agent VMs are maintained by vCLS. There’s no need for VI admins to power-off the VMs. In fact, the vSphere Client shows a warning when a agent VM is powered-off.

When a host is placed into maintenance mode, the vCLS agent VMs are migrated to other hosts within the cluster like regular VMs. Customers should refrain from removing, or renaming the agent VMs or its folder in order to keep the cluster services healthy.

The lifecycle for vCLS agent VMs is maintained by the vSphere ESX Agent Manager (EAM). The Agent Manager creates the VMs automatically, or re-creates/powers-on the VMs when users try to power-off or delete the VMs. Is the example below, you’ll see a power-off and a delete operation. Both from which the EAM recovers the agent VM automatically.

Automation and vCLS
For customer using scripts to automate tasks, it’s important to build in awareness to ignore the agent VMs in, for example clean-up scripts to delete stale VMs. Identifying the vCLS agent VMs is quickly done in the vSphere Client where the agent VMs are listed in the vCLS folder. Also, examining the VMs tab under Administration > vCenter Server Extensions > vSphere ESX Agent Manager lists the agent VMs from all clusters managed by that vCenter Server instance.

Every agent VM has additional properties so they can be ignored with specific automated tasks. These properties can also be found using the Managed Object Browser (MOB). The specific properties include:

ManagedByInfo
extensionKey == “com.vmware.vim.eam”
type == “cluster-agent”
ExtraConfig keys
“eam.agent.ovfPackageUrl”
“eam.agent.agencyMoId”
“eam.agent.agentMoId”
vCLS Agent VMs have an additional data property key “HDCS.agent” set to “true”. This property is automatically pushed down to the ESXi host along with the other VM ExtraConfig properties explicitly set by EAM.

Source: https://blogs.vmware.com/vsphere/2020/09/vsphere-7-update-1-vsphere-clustering-service-vcls.html

More Resources to Learn
vSphere 7 – Improved DRS
vSphere 7 – A Closer Look at the VM DRS Score
Load Balancing Performance of DRS in vSphere 7
What’s New with VMware vSphere 7 Update 1

The post vSphere Clustering Service (vCLS) – vSphere 7 Update 1 appeared first on COMIT Solutions.

To address this changing cybersecurity landscape, some companies have deployed multiple security point products. According to CSO Online, enterprises have an average of 75 products deployed to secure their network and cloud infrastructure. But these disparate point products pose challenges of their own, including management complexity and lack of interoperability — which in turn have led to an explosion in overall operating costs.

Today’s enterprises need a next-generation firewall that can accommodate the continuing increase in network traffic, while at the same time consolidating security controls to stop evasive threats.

Introducing SonicWall NSa 2700: A Gen 7 NGFW for Medium and Distributed Enterprises

The SonicWall Network Security Appliance (NSa) 2700 is a next-generation firewall (NGFW) that delivers industry-leading performance at the lowest total cost of ownership in its class. NSa 2700 protects mid-size networks with comprehensive integrated security services like malware analysis, encrypted traffic inspection, cloud application security and reputation services. It also supports centralized management with a truly intuitive single user interface, significantly improving operational efficiency.

SonicWall NSa 2700 includes advanced networking features such as HA/clustering, SD-WAN, dynamic routing, and virtual routing and forwarding. It combines validated security effectiveness and best-in-class price performance in a single rack unit appliance with high port density. In short, medium enterprises can now get the performance, networking and security capabilities they need from their next-generation firewalls without breaking the bank.

NSa 2700 Next Generation Firewall Highlights

Appliance at a glance

NSa 2700 is an energy-efficient, reliable appliance in a compact 1U chassis. Powered by the next-generation SonicOS 7.0 operating system, it is capable of processing millions of connections while delivering multi-gigabit threat prevention throughput. The following are a few high-level features that make NSa 2700 an attractive option for medium and distributed enterprises:

• 16 x 1 GbE interfaces
• 3 x 10 GbE interfaces
• 3 Gbps of threat prevention performance
• 6 Gbps of application inspection performance
• 5 million stateful and 500,00 DPI connections
• 21,500 connections per second
• Dedicated management port

Powered by the new SonicOS 7.0

The SonicWall NSa 2700 runs on SonicOS 7.0, a new operating system built from the ground up to deliver a modern user interface, intuitive workflows and user-first design principles. SonicOS 7.0 provides multiple features designed to facilitate enterprise-level workflows, easy configuration, and simplified and flexible management — all of which allow enterprises to improve both their security and operational efficiency.

SonicOS 7.0 features:

• Reassembly-Free Deep Packet Inspection® (RFDPI)and Real-Time Deep Memory Inspection™ (RTDMI)
• Secure SD-WAN
• High Availability/Clustering
• TLS 1.3 support
• Intuitive, single-pane-of-glass management
• Gateway Anti-Virus, Intrusion Prevention and Application Control
• Capture ATP Multi-Engine Sandboxing
• URL Filtering

More details about the new SonicOS 7.0 can be found here.

NSa 2700 Deployment Options

SonicWall NSa 2700 has two main deployment options for medium and distributed enterprises:

Internet Edge Deployment

In this standard deployment option, SonicWall NSa 2700 protects private networks from malicious traffic coming from the Internet, allowing you to:

• Deploy a proven NGFW solution with highest performance and port density (including 10 GbE connectivity) in its class
• Gain visibility and inspect encrypted traffic, including TLS 1.3, to block evasive threats coming from the Internet — all without compromising performance
• Protect your enterprise with integrated security, including malware analysis, cloud app security, URL filtering and reputation services

Medium and Distributed Enterprise Deployment

The SonicWall NSa 2700 supports SD-WAN and can be centrally managed, making it an ideal fit for medium and distributed enterprises. By leveraging NSa’s high port density, which includes 10 GbE connectivity, enterprises can support distributed branches and wide area networks. This deployment allows organizations to:

• Provide direct secure Internet access to distributed branch offices instead of back-hauling through corporate headquarters
• Allow distributed branch offices to securely access internal resources in corporate headquarters or in a public cloud, significantly improving application latency
• Reduce complexity and improve operations by using a central management system, which is accessed through an intuitive, single-pane-of-glass user interface

Overall Solution Value

The new NSa 2700 offers enterprises a best-in-class next-generation firewall with high speed and port density, all at a lower total cost of ownership. With integrated security services like malware analysis, URLF and cloud application security, NSa 2700 offers enterprises superb protection from advanced threats.

To learn more about the new NSa 2700, watch the video or click here.

Source: https://blog.sonicwall.com/en-us/2020/11/new-sonicwall-nsa-2700-high-performance-and-consolidated-security-at-lower-tco/

The post New SonicWall NSa 2700: High Performance and Consolidated Security at Lower TCO appeared first on COMIT Solutions.

The post In Business Special Feature appeared first on COMIT Solutions.