[Info-vax] VMware

[David Wade]

On 11/12/2019 02:15, Kerry Main wrote:
>> -----Original Message-----
>> From: Info-vax <info-vax-bounces at rbnsn.com> On Behalf Of Arne Vajhøj
>> via Info-vax
>> Sent: December 10, 2019 8:10 PM
>> To: info-vax at rbnsn.com
>> Cc: Arne Vajhøj <arne at vajhoej.dk>
>> Subject: Re: [Info-vax] VMware
>>
>> On 12/10/2019 2:45 AM, IanD wrote:
>>> Docker, another technology is making gains on VMware using a container
>>> technology but this is a topic for another day, I think OpenVMS may
>>> have to embrace contains at some point in time
>> Yep.
>>
>> Container technology are reducing the use of VM's.
>>
>> Kubernetes is probably the greatest threat to VMWare's business (even
>> though VMware of course try to get into that market as well).
>>
>> Containers in VMS would be cool. But I also think it would require a lot
> of
>> work - a lot more work than what it takes to make VMS run in VM's.
>>
>> Even though VMS actually have some building blocks that could be used to
>> support containers.
>>
>> Arne
>>
> 
> Most of what was stated in this thread is true i.e. virtualization has many
> benefits over most physical server hardware - especially in a Dev/Test world
> where spinning up the same baseline of an instance is important.
> 
> Keep in mind that Microsoft and Red Hat love this model because they get
> paid monthly support and OS licenses (MS) on a per instance basis. They
> could not care less if the OS instance was P or V.
> 

Its been a while but MS as far as I know on your own hardware Microsoft 
does not do "per instance" licence for server OS's. Enterprise per-core 
licences allow unlimited unlimited OS instances.

Standard Server OS licences are tie to the physical hardware so you need 
one per physical server meaning that this isn't typically a usefull model.

I am not sure about RedHat licensing but that seemed really expensive 
when we only had one server.

Oracle licencing was also a pain in the behind....

> The same will be true for OpenVMS.
> 
> If a company is running OpenVMS in a VM instance on VMware/KVM/Xen/???, and
> they decide to quickly spin up several OpenVMS Dev instances, then VSI will
> require support and maybe license costs (depending on V9+ support model) on
> a per instance basis. That is great for VSI as well.

As I said Microsoft on an internal farm do not require per instance 
licences. VSI are free to define their own model. Getting a balance 
between models will be hard as its a speciality

> 
> Having stated this, there is a lot of practical reality though that unless
> you are in a larger shop, most people may not realize are real challenges.
> 
> Yes, you can put a large number of VM's on a single server, but you also
> need humungous amounts of physical memory on that server which adds huge
> costs to each physical server. I have seen quotes for enterprise ProLiant's
> with 1-2 TB's of memory in the $250,000 range - per server! And then the
> VMware and any COTS application licenses costs are in addition to this.
> 

Again getting the right server size is more challenging in a Virtual 
environment. I prefer smaller servers because that allows more 
granularity in the environment. So having a $100K server means when you 
want to grow you can do it in $100k chunks, with a $200k server than its 
a $200k step. Assuming you want resilience and you think one spare 
server is enough qith the $100k server that's $100k sat in reserve...

... of course thats not the only consideration. Network and SAN 
connectivity may also impact on costs so for any organization the 
sweetspot may be hard to find...


> Also, keep in mind that if using COTS products that are licensed per core,
> then you definitely want to keep that COTS product on its own small VMware
> cluster - just ask those who deploy Oracle on VMware.
> 
> Yes, VMware (and its equivalent competition) solved the issue of the wild
> west of the 80's and 90's where every dept had their own local servers i.e.
> server sprawl.
> 

Yes SQL server has the same problems as Oracle. We used to have a 
separate smaller farm for SQL server...

> Now, however, large companies have the problem of VM sprawl. Where they
> might have managed 40-80 physical servers before, they now manage hundreds
> of separate VM's. A common question from IT C levels is "how come our IT
> costs keep going up even though we consolidated all the physical servers we
> had before?"
> 

Yes...

> In addition, being able to spin up VM's quickly is great if the application
> is architected such that the workload can be spread across many servers.
> While this may be true for new Apps written in the last 10-15 years, the
> reality is that the vast majority of legacy and COTS apps in enterprise DC's
> are not architected in such a way.
> 

which drives you towards larger servers

> The other issue with VM sprawl is that of license costs for such things as
> licensing backup agents, AV agents (do you really want to ignore AV
> issues?), log file monitoring (for those who care about per instance
> security monitoring), scheduler agents, service desk integration (smart
> ticketing) and other host based management and monitoring (M&M) agents.
> 
> Sure, if the company wants its senior developers to spend a great deal of
> their time developing freeware solutions to the M&M challenges above, then
> these per instance M&M costs can be mitigated somewhat.
> 

Freeware solutions are great but the long terms costs are challenging

> If the company would prefer to have its senior developers adding
> functionality which adds value to its core applications, then that company
> is more likely to be of the frame of mind to simply use commercial agents
> (they still require integration, but typically less so than freeware
> options) where they have a single throat to choke.
> 
> In terms of building new Apps which are heavily distributed to take
> advantage of many, many VM's, these are not without its challenges as well
> in terms of data caching, consistency, coherency, complexity etc.
> 
> Certainly there are some ways to address these challenges (just ask google
> and FB), but as others have stated here - it is not a slam dunk as to what
> model is best suited to address any given set of requirements.
> 
> A summary of building highly distributed app challenges can be seen in this
> article from 2015:
> "Making the Case for Building Scalable Stateful Services in the Modern Era"
> <http://highscalability.com/blog/2015/10/12/making-the-case-for-building-sca
> lable-stateful-services-in-t.html>
> 
> 

I would also say that its much easier to do proper Disaster Recovery 
with VMS. I not in another thread some one sited the 737 through the 
window. Well having worked in an office on Manchester (UK) approaches 
and where an A380 flies in twice a day and where we were about 600 yards 
from the site of a previous (1960's) air crash we took DR seriously.

There is an off-site duplicated SAN. Its not lock stepped but its a 
whole load better than the previous solution with daily tapes....


> Regards,
> 
> Kerry Main
> Kerry dot main at starkgaming dot com
> 
> 
Dave Wade