Speaker 1: Welcome back to another deep dive. Today. We're opening up
Speaker 1: a topic that I think a lot of us in
Speaker 1: the crunches have a bit of a love hate relationship with.
Speaker 2: OHI JEFFA.
Speaker 1: We are talking about vSphere seven point X, and I
Speaker 1: know the immediate reaction for you listening is probably great.
Speaker 1: Another update, another version number to track. But we've been
Speaker 1: pouring over the official cert guide for EXAM two V
Speaker 1: zero DASH twenty one point two. Yeah, that's by Davis,
Speaker 1: Baka and Thomas And honestly, this feels different. It really
Speaker 1: doesn't feel like just a service pack.
Speaker 2: It really isn't. I mean, when you actually dig into
Speaker 2: the architecture changes let out in this guide, VRE seven
Speaker 2: represents a massive pivot.
Speaker 1: Ye.
Speaker 2: It's the exact moment where VMware stopped just virtualizing servers
Speaker 2: and really started enforcing the software to find data center
Speaker 2: the SDDC. We're moving from a world where we manage
Speaker 2: individual boxes to a world where we manage policies in
Speaker 2: desired states.
Speaker 1: Desired state that is the buzzword, right, Yeah, But looking
Speaker 1: at the source material here, there is some serious engineering
Speaker 1: behind that marketing term. Absolutely, we've got the death of
Speaker 1: the external platform services controller, finally long.
Speaker 2: Overdue, the complete overhaul of how storage is handled with
Speaker 2: VSN and vvols, and some pretty scary warnings about where
Speaker 2: you can and cannot install ESXi anymore.
Speaker 1: Yeah, it's a lot to unpack. The guide is dense
Speaker 1: because the changes are so fundamental. They're basically ripping out
Speaker 1: legacy code that has been there for a decade and
Speaker 1: replacing it with this modern container aware architecture.
Speaker 2: So let's start with the brain of the beast vsenter server. Now,
Speaker 2: if you're listening and you were running visphere six point
Speaker 2: zero or six point five, you probably have battle scars
Speaker 2: from dealing with the Platform Services Controller, the ps.
Speaker 1: OH, the topologies.
Speaker 2: I remember having to design these incredibly complex topologies with
Speaker 2: external ps sitting behind third party load balancers just to
Speaker 2: get single sign on to work across sites. It was
Speaker 2: frankly a nightmare.
Speaker 1: It was incredibly complex. You had to manage replication agreements
Speaker 1: between those PSCs, You had to manage the certificates for
Speaker 1: each individual one.
Speaker 2: The certificates were the worst, right and if the load
Speaker 2: balance er misbehaved, your admins literally couldn't log in. But
Speaker 2: the good news from the cert guide is that VS
Speaker 2: seven effectively kills the external psc.
Speaker 1: So it's dead, Like I don't have to build them anymore.
Speaker 2: It is dead. The entire architectures that collapsed back into
Speaker 2: a simplified single appliance model. Okay, all those services, single
Speaker 2: sign on, the license service, the VMware Certificate Authority, They're
Speaker 2: all now running natively inside the v Center Server appliance
Speaker 2: the VCSA.
Speaker 1: Okay, that sounds great for a greenfield deployment, but what
Speaker 1: about the poor admin out there who has that complex
Speaker 1: six point seven topology with external PSCs. Is the upgrade
Speaker 1: path going to be a complete rip and replace scenario?
Speaker 2: Surprisingly, no, The guide highlights that the upgrade tool is
Speaker 2: actually a converge tool. Oh interesting, When you run the
Speaker 2: VS verse seven installer against your existing environment, it actually
Speaker 2: detects those external ps migrates their data and identity into
Speaker 2: the new vCenter appliance, and then essentially decommissions the old nodes. Ah,
Speaker 2: it converges the topology automatically for you.
Speaker 1: That is a huge relief to hear. But there's another
Speaker 1: obituary in here. The guide is pretty explicit that vCenter
Speaker 1: Server for Windows is.
Speaker 2: Gone correct, done, no more installing v Center on top
Speaker 2: of Windows Server. We are strictly in the world of
Speaker 2: the Photonos appliance now, right, which is great for security
Speaker 2: and patching, but it does mean if you are relying
Speaker 2: on Windows specific scripts or agents running locally on your
Speaker 2: v center box.
Speaker 1: Which a lot of people did exactly.
Speaker 2: That workflow is completely broken. Now you have to adapt.
Speaker 1: Okay, So we have this single monolithic appliance now handling everything.
Speaker 1: It's the brain, the heart, and the nervous system. But
Speaker 1: if that appliance dies, we are flying blind. I know
Speaker 1: v Center High Availability existed before, but the guide makes
Speaker 1: it sound like the architecture under the hood has really changed.
Speaker 1: How are we keeping this thing alive?
Speaker 2: So? vCenter ha and version seven is very slick, but
Speaker 2: you have to understand it requires specific networking. It uses
Speaker 2: a three node cluster. Okay, you've got an active node,
Speaker 2: a passive node and a witness note walk.
Speaker 1: Us through the replication. There is this just doing a
Speaker 1: standard storage mirror.
Speaker 2: No, No, it's much more intelligent than the active node.
Speaker 2: The one you are actually logged into and using is
Speaker 2: replicating data to the passive node through two distinct channels.
Speaker 2: Two channels, right, it uses native postgracle replication for the database,
Speaker 2: ensuring that all your inventory and events are SYNCD transactionally.
Speaker 2: And then it uses a separate file level replication basically
Speaker 2: zer sync to keep the configuration files in check.
Speaker 1: And the WITNESS is that just a third copy of
Speaker 1: the database.
Speaker 2: Not at all. The WITNESS is just a tiebreaker. It's
Speaker 2: a very lightweight clone. It doesn't hold the database or
Speaker 2: the files.
Speaker 1: Noo, what does it do?
Speaker 2: Its only job is to provide quorum. If your network
Speaker 2: kickups and the active and passive nodes lose sight of
Speaker 2: each other, you run the massive risk of a split
Speaker 2: brain scenario where both think they are the mas.
Speaker 1: Right, which corrupts everything exactly.
Speaker 2: The WITNESS basically casts the deciding vote on who actually.
Speaker 1: Owns the cluster, and the guide mentions some strict requirements
Speaker 1: for this right. You can't just throw these nodes anywhere
Speaker 1: on your network.
Speaker 2: No, you really can't. You need a dedicated vCenter HA
Speaker 2: network interface on each node, and the latency required is strict,
Speaker 2: how strange, less than ten milliseconds between the active and
Speaker 2: passive nodes. If you try to stretch this across a
Speaker 2: laggy wham link, the Postgres school replication will time out
Speaker 2: and the cluster will just fail.
Speaker 1: Get to know. So we've bulletproofed the brain, but the
Speaker 1: brain is useless if the body, meaning the esx offs themselves,
Speaker 1: are crumbling.
Speaker 2: That's true, and.
Speaker 1: That brings us to a somewhat controversial change in the
Speaker 1: guide regarding how we actually boot these servers.
Speaker 2: Oh yeah, the boot media.
Speaker 1: For years in my home lab, and honestly even in
Speaker 1: some production environments, I just slap ESXi on a generic
Speaker 1: eight gig USB stick or an SD card. It was cheap,
Speaker 1: it worked. But reading this guide, it sounds like VMware
Speaker 1: is declaring war on USB boot drives.
Speaker 2: War might be a strong word, but they are definitely
Speaker 2: waving a massive red flag for you. The issue isn't
Speaker 2: just the capacity, it's the partition structure.
Speaker 1: Okay, break that down.
Speaker 2: In previous versions, that boot drive really just held the
Speaker 2: hypervisor image, which is tiny. It loads into memory and
Speaker 2: it's done. But VS seven introduces a completely new partition layout.
Speaker 2: The big one you need to know about is ESXOS data.
Speaker 1: ESXOS data. That sounds ominous. What goes in there?
Speaker 2: It's consolidation. It takes the old scratch partition, the locker
Speaker 2: for VMware tools and the core dump location and puts
Speaker 2: them in one place. But here is the kicker. It
Speaker 2: is formatted with VMFSL.
Speaker 1: VMFSL like the filesystem used in VSL.
Speaker 2: Exactly like that. It's a high performance filesystem designed specifically
Speaker 2: for frequent reads and writes. This partition stores system logs, traces,
Speaker 2: and live database entries for the host itself.
Speaker 1: Okay, I see where this is going.
Speaker 2: Right. If you put that kind of heavy IO load
Speaker 2: on a cheap consumer grade USB stick or an SD card,
Speaker 2: you're going to burn out those nan flash cells in
Speaker 2: a matter of months, maybe even weeks.
Speaker 1: So the hypervisor is literally.
Speaker 2: Right rights to drive to death. Yes, And because of this,
Speaker 2: if the installer detects you or booting from a low
Speaker 2: quality USB device, it creates the esx O STATA partition,
Speaker 2: but it runs it into.
Speaker 1: Graded mode degraded mode.
Speaker 2: Yeah, it tries to limit the rights to save the drive,
Speaker 2: but you lose functionality and your logs are seriously at risk.
Speaker 1: So what is the actual recommendation from the cert guide?
Speaker 1: Are we going back to spinning rest for boot drives?
Speaker 2: The guide firmly recommends a local persistent disc that means
Speaker 2: an HDD or an SSD of at least thirty two gigabytes.
Speaker 2: That gives you enough room for the boot banks and
Speaker 2: a fully functional esx ostate a partition.
Speaker 1: And if you absolutely have to use USB.
Speaker 2: If you must use USB, you have to pair it
Speaker 2: with a local disc to offload that scratch partition, or
Speaker 2: you are living on borrowed time.
Speaker 1: That is going to catch a lot of people off
Speaker 1: guard during a hardware refresh. Speaking of things that catch
Speaker 1: people off guard are DNS and NTP classics. I feel
Speaker 1: like we talk about this every year, but the guide
Speaker 1: is just relentless about it.
Speaker 2: This time. It has to be in vSphere seven. The
Speaker 2: dependencies are hard coded. Take DNS for example, when you
Speaker 2: are deploying that new VCSA, the installer pauses and actually
Speaker 2: performs a reverse look up on the IP address you provided.
Speaker 2: If it cannot resolve that IP back to the fully
Speaker 2: qualified domain name the FQDN, the installation literally fails. It
Speaker 2: doesn't warn you, it just stops.
Speaker 1: Zero tolerance.
Speaker 2: Zero tolerance and NTP is even more critical because of
Speaker 2: sso how so the authentication tokens, the insale tokens used
Speaker 2: between v center and the hosts. They're all time stamped.
Speaker 2: If your host drifts more than a few minutes away
Speaker 2: from the v center time those tokens are rejected. Oh man,
Speaker 2: suddenly your backups fail, v motion fails and you literally
Speaker 2: can't log into the host.
Speaker 1: So for everyone listening, check your PTR records and your
Speaker 1: time servers before you even download the IO.
Speaker 2: The un sexy work that saves the deployment, let's.
Speaker 1: Shift gears to something a little sexier, store orridge. This
Speaker 1: seems to be where the software defined part of SDBC
Speaker 1: really kicks into overdrive. Absolutely, we still have the classics
Speaker 1: VMFS and NFS. Are they just legacy support now or
Speaker 1: have they actually improved in this version?
Speaker 2: Oh, they've definitely evolved. VMFS six is the absolute standard
Speaker 2: now and the big thing it handles is automatic unmap.
Speaker 1: You m in how that works.
Speaker 2: In the old days, if you deleted one hundred gigs
Speaker 2: of data inside a Windows VM, the underlying storage ray
Speaker 2: had no idea that space was free. It stayed marked
Speaker 2: as used. VMFS six automatically sends commands down to the
Speaker 2: array to reclaim that space.
Speaker 1: That's a huge space saver. And what about NFS. I
Speaker 1: usually associate NFS with holding isophiles, not running high performance workloads.
Speaker 2: Right, But VS seven pushes NFS four point one, which
Speaker 2: is a massive leap over NFS three. The two big
Speaker 2: features you get are multipathing and cerberos.
Speaker 1: Okay, multipathing makes sense.
Speaker 2: Yeah, NFS three relied on a single TCP session. If
Speaker 2: that link got saturated, you were bottlenecked. NFS four point
Speaker 2: one supports true multipathing across multiple links, and Cabero's means
Speaker 2: we can finally encrypt that storage traffic on the.
Speaker 1: Wire, which is a huge compliance requirement for a lot
Speaker 1: of organizations. Now exactly, now, I saw an acronym in
Speaker 1: the guy that was new to me, HPP, the high
Speaker 1: performance plug in. For the last decade, we've relied on NMP,
Speaker 1: the native multipathing plug in. Why do we need a
Speaker 1: new one? Now?
Speaker 2: This is entirely driven by the rise of NVMe non
Speaker 2: volatile memory express. Think about NMP as a traffic cup
Speaker 2: that was designed for traffic in the nineteen nineties, spinning discs.
Speaker 1: Right.
Speaker 2: It has these complex locks and queues that made total
Speaker 2: sense when drives were slow, But modern in VM flash
Speaker 2: is so incredibly fast that the software stack NMP itself
Speaker 2: actually became the bottleneck.
Speaker 1: The software couldn't click the send button fast enough for
Speaker 1: the hardware.
Speaker 2: Precisely, so VMware wrote the HPP specifically for ENVME and
Speaker 2: nvmey over fabrics. It removes those legacy locks and optimizes
Speaker 2: the whole iopath to handle millions of IOPs without killing
Speaker 2: your CPU over.
Speaker 1: So, if you're buying an all flash NVM array today,
Speaker 1: you need to be using HPP.
Speaker 2: If you aren't, you're just wasting the money you spend
Speaker 2: on that array.
Speaker 1: This moves us nicely into the no More Lams conversation
Speaker 1: vivols or virtual volumes. The concept has been around for
Speaker 1: a while, but the guide really treats it as a
Speaker 1: primary citizen in version seven for those who haven't deployed it.
Speaker 1: What is the actual mechanism here?
Speaker 2: So vviles changes the entire relationship between vCenter and the
Speaker 2: storage array. It introduces a component called the VSA.
Speaker 1: Provider vSphere APIs for Storage Awareness right.
Speaker 2: This acts as a translator. Instead of the array presenting
Speaker 2: a dumb ten terabyte block of space a LN, the
Speaker 2: VISA provider tells vsenter, hey, I can do replication, I
Speaker 2: can do dduplication, and I can do encryption, And then
Speaker 2: v center pushes that policy down to the individual VM level. Exactly.
Speaker 2: When you create a VM, the array creates a specific
Speaker 2: virtual volume just for that VM's disc. If you need
Speaker 2: to snapshot that VM, the array snapshots only that volume.
Speaker 2: You aren't snapshotting a whole li in with twenty other
Speaker 2: vms on it.
Speaker 1: It gives you granular control that matches the application, not
Speaker 1: the hardware limitations exactly. But if we really want to
Speaker 1: talk about true software defined storage, we have to talk
Speaker 1: about VSAM. This really feels like the heart of the
Speaker 1: modern VMware stack. Conceptually, we're taking local discs in the
Speaker 1: servers and pulling them across the network. But the devil
Speaker 1: is always in the details, specifically regarding disc groups.
Speaker 2: The disc group is the fundamental building block of VSAN.
Speaker 2: Each host participating needs at least one and the strict
Speaker 2: rule laid out in the guide is one cash device
Speaker 2: and one or more capacity devices.
Speaker 1: Per group, and that cash device is non.
Speaker 2: Negotiable, completely non negotiable. It must be flash. Even in
Speaker 2: a hybrid cluster where your capacity tier is made of
Speaker 2: cheap spinning discs, that cash tier has to be high
Speaker 2: performance SSD. Why is that because it absorbs one hundred
Speaker 2: percent of the right operations. It acts as a buffer.
Speaker 2: And here's the critical part. If that cash drive fails,
Speaker 2: the entire disc group go offline.
Speaker 1: Wow. Now the guide gets into some math that I
Speaker 1: think is really important for anyone doing capacity planning. It
Speaker 1: talks about RAD five and RADE six erasure coding. Traditionally,
Speaker 1: if I wanted redundancy, I use RAD one mirroring. I
Speaker 1: have one hundred gigs of data. I need two hundred
Speaker 1: gigs of disk space.
Speaker 2: Right, a two hundred percent overhead. That gets incredibly expensive
Speaker 2: when you're buying enterprise flash drives. Erasure coding changes the algorithm.
Speaker 2: It stripes the data across the host with parity.
Speaker 1: Bits like old school hardware RAID five.
Speaker 2: Very similar logic, but distributed across the network instead of
Speaker 2: a bad plane. With RAD five eraser coding, you need
Speaker 2: a minimum of four hosts. It uses a three plus
Speaker 2: one calculation, so your overhead drops from two x down
Speaker 2: to about one point three to three acts. That's signific
Speaker 2: You get the exact same level of protection, but you
Speaker 2: save a massive amount of raw storage capacity.
Speaker 1: That is a huge cost difference at scale. But it's
Speaker 1: only available on all flash configurations right.
Speaker 2: Correct, The parody calculation requires significant CBU and random io performance.
Speaker 2: Spitting discs simply cannot keep up with the read modify
Speaker 2: right penalty of erasure coding without totally tanking your VM performance.
Speaker 1: Got it now. One of the most fascinating topologies in
Speaker 1: the guide is the stretched cluster. This is the scenario
Speaker 1: where you have two data centers, Site A and Site B,
Speaker 1: and you want them to essentially act as one giant cluster.
Speaker 1: But I've always wondered about the split brain problem here.
Speaker 1: If the fiber line between the buildings gets cut, how
Speaker 1: do you stop them from fighting over who is the
Speaker 1: active site.
Speaker 2: That's the classic two generals problem, and VSAN solves this
Speaker 2: with a witness host. You place this witness in a
Speaker 2: third location, a totally different fault domain from Site A
Speaker 2: Insight BK, and it holds the metadata components of the VSN.
Speaker 1: Objects, so it acts as the referee.
Speaker 2: Exactly imagine Site A in Sight B lose connection. Site
Speaker 2: A looks at the witness and says, hey, can you
Speaker 2: see me? The witness says yes. Sit A then knows
Speaker 2: it has a quorum. It has two out of three votes,
Speaker 2: so it stays online and Site B Site B can't
Speaker 2: see the witness or site A, so it mathematically knows
Speaker 2: it has lost the vote. It immediately shuts down its
Speaker 2: VMS to prevent any data corruption.
Speaker 1: And since the witness only holds metadata, it can run
Speaker 1: on a pretty small connection, right, Yeah.
Speaker 2: It's tiny. You can run it inside a small cloud
Speaker 2: instance or just an old server in a remote office.
Speaker 2: It's not storing the actual VMDK data, just the state
Speaker 2: of the data.
Speaker 1: This all leads to the overarching philosophy of vSphere seven,
Speaker 1: which is SPBM storage policy based management. It feels like
Speaker 1: we are finally moving away from the old gold, silver
Speaker 1: bronze lun mindset.
Speaker 2: That is absolutely the goal. In the past, the infrastructure
Speaker 2: dictated the policy. You'd say, I have a fast lun,
Speaker 2: so put the database there. With SPBM, the application dictates
Speaker 2: the infrastructure.
Speaker 1: How does that look in practice?
Speaker 2: You create a policy and vCenter say mission critical encryption
Speaker 2: enabled RAD one protection. Yeah, you just assigned that policy
Speaker 2: directly to.
Speaker 1: The VM, and v center acts as the broker exactly.
Speaker 2: V center looks at your VM data store or your
Speaker 2: vfles and checks can I satisfy this requirement? If yes,
Speaker 2: it places the VM. If say six months later, a
Speaker 2: drive fails and the VM is no longer protected. V
Speaker 2: Center flags it as non compliant.
Speaker 1: That's a big shift. It changes the admin's job from
Speaker 1: provisioning storage to monitoring compliance.
Speaker 2: It's all about desired state.
Speaker 1: Before we wrap up, we have to touch on the
Speaker 1: integration of modern apps. The guide mentions first class discs
Speaker 1: and Kubernetes support. I think a lot of infrastructure admins
Speaker 1: here Kubernetes and just tune out, thinking it's purely a
Speaker 1: developer problem. But vsp seven makes it an infrastructure problem.
Speaker 2: It really does. The concept of the first class disc
Speaker 2: or STD is crucial here. In the past, a virtual
Speaker 2: disc was always a child of a virtual machine. If
Speaker 2: you deleted the VM, the disc died.
Speaker 1: With it, which is fine for a traditional server, but
Speaker 1: really bad for a container exactly.
Speaker 2: Containers are ephemeral. They spin up and die in seconds,
Speaker 2: but the data they generate, like a database file, needs
Speaker 2: to persist. A first class disc is a managed storage
Speaker 2: object that exists completely independently of any.
Speaker 1: V so it just floats out there.
Speaker 2: Yes, and kuberd eddies can request storage. vSphere creates an
Speaker 2: FCD and that disc can be attached and detached to
Speaker 2: different container worker nodes as needed. It allows you to
Speaker 2: run staple apps on the exact same VSR platform you
Speaker 2: use for your traditional Windows servers.
Speaker 1: So bringing it all together, vSphere seven isn't just a facelift.
Speaker 1: It is a fundamental re architecture. We've killed the external
Speaker 1: PSC and simplified the management plane. We've tightened the screws
Speaker 1: on hardware reliability with VMFSL boot partitions and those strict
Speaker 1: DNS requirements. And we've moved storage from a static hardware
Speaker 1: mapping to a dynamic, policy driven engine. With VAN and SPBM,
Speaker 1: it's really.
Speaker 2: About vSphere becoming the universal platform. Whether it's a legacy
Speaker 2: SQL server or cloud native micro service, the goal is
Speaker 2: to manage them with the exact same policies, the same availability,
Speaker 2: and the same security.
Speaker 1: I want to leave you with one final thought from
Speaker 1: the guide something called life Cycle Manager. We didn't have
Speaker 1: time to deep dive into it today, but it applies
Speaker 1: that same desig hired state logic to the hardware firmware itself.
Speaker 1: It can actually push BIOS and HbA driver updates to
Speaker 1: the physical servers to match a policy you set.
Speaker 2: It's an absolute game changer. It means you aren't just
Speaker 2: patching ESXC anymore. You are patching the actual metal underneath
Speaker 2: it all directly from vCenter.
Speaker 1: Right, and if vSphere is managing the physical firmware, the
Speaker 1: storage controller, and the application policy, are we looking at
Speaker 1: the end of the traditional hardware maintenance window as we
Speaker 1: know it. It feels like we are getting closer to
Speaker 1: the dream of a truly fluid infrastructure.
Speaker 2: We are definitely getting there. The hardware is basically just
Speaker 2: becoming code at this point.
Speaker 1: Plenty to think about before your next upgrade. Check those
Speaker 1: boot partitions, verify your dns, and maybe start playing with
Speaker 1: SPBM in your lab. Thanks for joining us on this
Speaker 1: deep dive into VC or seven.
Speaker 2: So glad to be here.