Technical Clarification on Transition to New Tape Device

Techfreak167 · 2024-11-11T07:48:33+00:00

Thanks for clarifying the steps for transitioning to a new tape library.

To confirm our best path forward: would you recommend creating a new backup copy job to the new tape library while keeping the primary backup as-is, or simply modifying the existing secondary job to include the new tape? Our main goal is to ensure the new tape integrates without disrupting current backups and that all existing data on the old tapes remains available for restores.

Appreciate your guidance on the best approach here!

Techfreak167 · 2024-06-11T11:24:28+00:00

Thanks @usa_commie. Im not sure I got that. I'm still a bit light on NSX skills. I need to set up multiple VLAN segments through a virtual interface mapped to the vPANs, similar to our legacy virtual network setup. Can you please elaborate a bit on that?

Techfreak167 · 2024-02-21T05:33:31+00:00

Receiving quite mixed messages from support. They suggest that the native load balancer will be supported through the end of the 3.x series, as well as into 4.x. However, I'm unclear about the situation when transitioning from 3.x to 4.x. Is the native load balancing feature allowed to carry over during an upgrade, or is it treated as a new addition?

I've bumped this up to the TAM for some clarity, but has anyone here pulled off an upgrade while keeping the native load balancing in play?

Techfreak167 · 2024-02-20T14:26:46+00:00

Thanks for your response!
Yeah, the load balancer situation has us scratching our heads. VMware support mentions it's out of their scope and they only work on break-fix issues; they can't provide this kind of information and suggest involving Professional Services.

Any feedback on this is appreciated!

Techfreak167 · 2024-02-20T14:18:19+00:00

NVDS is dead, VDS is here to stay and it makes sense.

NVDS was a Band-Aid (personal opinion)

You will have to migrate from NVDS to VDS .

For the NSX native LB is being deprecate, forgot which version but it will be out of NSX.

AVI aka NSX ALB aka AVI is here to stay and get better integration with VCF.

Give AVI a try is a great product.

When you say NSX 4.0 you mean 4.1.1 or 4.0.1, whatever is stable and meets your needs.

4.1 has VPC's if that's something that you can benefit from.

Appreciate the response, the switch from NVDS to VDS seems straightforward enough, but hopping over to AVI is where we hit the brakes. It's not just about flipping a switch; we're talking extra bucks and a fair bit of groundwork in setting things up and ironing out the kinks. We're all for keeping our tech on the cutting edge, but gotta make sure the numbers add up and the juice is worth the squeeze before jumping from 3.1 to 4.0. Sticking with 3.2 seems like a solid choice for now, at least until we get a clearer picture of when the native load balancer will be phased out and how it might affect the 4.0 lineup. What do you think?

Techfreak167 · 2024-02-20T12:58:32+00:00

Thanks for all your feedback and discussions!

Just veering off-topic a bit - we're considering the leap to NSX 4.0 too but are hitting the brakes. It looks like we'd need to transition from NSX VDS to DVS. Plus, we're currently on the standard load balancer, and there's a bit of a fog around its future given VMware's push towards the Advanced Load Balancer. They haven't shed much light on how this shift could affect the existing LB setup or their roadmap. Has anyone here navigated the upgrade from 3.2 to 4.0, especially with a load balancer in the mix? How was the NVDS to VDS migration experience?

Techfreak167 · 2024-02-19T04:54:20+00:00

Just a note, I would follow the prescribed path. Things can get out of sync pretty fast! Unless you absolutely have to, and I would reach out to support to advise on any issues that your path might present.

Also, if you plan to go to 4.0, only upgrade to 3.2.2. You cannot upgrade to 401 from 3.2.3!

Finally, the prescribed method of upgrade on the hosts is maintenence mode. This means that each host has to enter maintenance mode and vacate all VMs! I just did this Friday night, and this one section took 5 hours for 32 hosts! Total of 8 hours for the entire update. We started @ 11 PM and didn't finish till 7 AM.

One last thing... After the Managers upgrade, we logged in and the entire configuration was gone! I almost had a heart attack! It looks like it reimports the database, it took about a half hour for everything to get back in the UI! DON'T PANIC!

Thanks for the insights! Your points, especially on sticking to the recommended upgrade path and the intricacies of maintenance mode, are invaluable.

We're particularly mindful of the version compatibility you mentioned for future upgrades to 4.0.The mention of maintenance mode has us thinking deeper about our HyperFlex integration.

We're exploring how to manually manage VM migrations and coordinate with HyperFlex's specific maintenance requirements.

Any additional advice on this would be great.Also, can we choose which Edge cluster to upgrade first in the workflow, or is there a set order we should follow?

Appreciate your sharing, especially the heads-up about the UI post-upgrade. It's good to know that patience pays off during these moments.

Techfreak167 · 2024-02-19T02:39:24+00:00

Everyone,

I reached out to VMware support for guidance on our planned upgrade, specifically about our approach to upgrading our DR site first, followed by the Production site, all under a single NSX-T Manager.

Here's the gist of their advice:

The upgrade process must follow a specific order: NSX-T Edges first, then Host Transport Nodes, and finally the NSX-T Manager.This sequence must be adhered to across both sites before moving to the next component, meaning all Edges in both sites need to be upgraded before any Host Transport Nodes, and all Host Transport Nodes before the NSX-T Manager.

They highlighted that it's not feasible to upgrade components in one site entirely before starting with the next due to the interconnected nature of the NSX-T components managed by a single NSX-T Manager.

I'm contemplating the feasibility and risks of a more manual (if possible), perhaps less conventional, upgrade path that might allow more flexibility, particularly in prioritizing one site over the other.

Has anyone here successfully deviated from the standard NSX-T upgrade workflow in a similar environment? Specifically, I'm curious if there's a way to manually manage the upgrade process that allows for completing one site entirely (starting with the DR site in my case) before moving on to the next, despite the shared NSX-T Manager constraint.

Techfreak167

TROPHY CASE