Two Minute Shape

Strategix · Nutanix .NEXT Johannesburg

The shape of it, in two minutes

Eleven questions, most of them a tap. A range, not a quote - and the things nobody tells you until you are already committed.

Question 1

What are you running today?

Everything after this adapts to your answer. If it is more than one thing, pick the one that carries most of the workload.

Question 2

Roughly how many virtual machines?

A ballpark is fine. This sets the floor for everything else.

Question 3

Total memory allocated to them

Allocated, not used. That distinction turns out to matter more than anything else on this page - we will show you why.

GB

Assumed at 18 GB of memory per machine, from a real production estate we measured ourselves. Change it if you know your own figure.

Your own figure - we will not overwrite it.

Question 4

Total virtual CPUs allocated

Again allocated, across all machines.

vCPU

Assumed at 5 virtual CPUs per machine, from a real production estate we measured ourselves. Change it if you know your own figure.

Your own figure - we will not overwrite it.

Question 5

Storage actually in use

What the machines consume, not what the array holds.

TB

Assumed at half a terabyte of storage per machine, from a real production estate we measured ourselves. Change it if you know your own figure.

Your own figure - we will not overwrite it.

Question 6

When does your current agreement end?

This changes the advice more than any technical answer.

Question 7

-

Question 8

-

Question 9

What backs it up?

Question 10

What do you monitor with?

Question 11

Any of these in the estate?

Tap all that apply. These need handling separately, and it is better to know now.

An indicative shape - not a sizing

-

nodes

Modelled on our own migration off VMware, not on an industry average.

What is driving it

-

-

Processor - modelled on our own numbers

-

-

The thing nobody mentions

The target platform does not overcommit memory

-

-

One worked alternative

If you right-sized first

-

What you would be licensed on

-

-

Raw is not usable

-

-

Your rebuild list

Things that do not move across

For each one: what does the job on the new platform, what the move actually involves, and what changes once you are living with it.

The management plane

-

-

What we have NOT counted

Things that will add to this, and we would rather say so

  • A separate management cluster. Once you are running more than one tenant, or at any real scale, leading practice puts the management plane on its own cluster with its own resilience floor. That is nodes on top of the number above, and whether you need one is a design decision rather than a calculation.
  • Backup infrastructure. The new platform has no equivalent of the transport your current product uses, so it deploys worker machines onto the cluster itself - which consume the cores you are licensed for.
  • The migration tooling. A small appliance, and only for the duration, but it has to live somewhere while it runs.
  • The controller's own footprint on disk. We have deducted its memory and accounted for its processor, but its system and metadata space on the drives is inside our working headroom rather than counted separately.
  • Anything you stand up new - file services, database services, monitoring you have to replace, a test cluster.

What we could not see

Being straight with you

-

If you do one thing

-

-

Your reference -

This part is yours, not ours

Please type your own email address, tick the boxes yourself and press send. If a Strategix person is standing with you, ask them to hand the device over now. We do not complete this bit for you.

Your consent is recorded with the date, time and where it was given. We will tell you in the email who holds your information, what for, how long, and how to have it removed. [Privacy wording to be confirmed with Marketing.]

On its way

-

Two links in it: your report, and the paper on what we learned migrating our own production cloud off VMware. No forms, no details to enter again.

Your reference -

This is a shape, not a sizing. It is built from eleven answers and a set of stated assumptions, and a real number needs measured data from your own estate. We would rather tell you that than pretend otherwise - a sizing done badly is worse than none, because it ends up in front of your board.

What we assumed. Two copies of the data, one node's worth of capacity held back so the cluster can rebuild itself, working headroom of eight percent, and no data-reduction savings claimed at all - the features that would provide them sit at a higher licence tier and do not suit every workload. A four-node floor, because a three-node cluster stops meeting its own resilience minimum the moment one node is down. Memory for the storage controller on every node, and an allowance for the management plane. Where you did not have a figure to hand we assumed it from your machine count, using averages from a production estate we measured ourselves, and we have said so above every figure we filled in. What we have not counted is listed on the result, in full. Strategix Technology Solutions.