I'm shutting our site totally down next month for about 15 mins. The head of IT is getting a bit twitchy about his UPS's !
So virtualise them all, then you can move the VMs and empty the physical server.Asking people to log off to be able to test is common and with servers finding windows to do work again common. But switching off is still a problem.
Do they?Often they need switching on in a set order.
Twaddle.However servers should not be supplied with extension leads where loss of power will cause problems. They should have all been on their own UPS and no two servers should be connected to the same UPS in the same way as one would not plug in two shavers to the same shaver socket.
All down to loss of earth connection when power is lost. One machine goes to one supply.
There wasn't in this case - just a "kettle lead" from machine to wall.So although the guy doing PAT testing may have made an error, clearly so had the guy or guys setting up the servers in the first place. There simply should not have been an extension lead between server and supply.
There probably was a label at the wall socket. But, regardless of whether it is a PC or a server, there isn't an excuse for someone unplugging a piece of IT equipment that's obviously running without getting someone to shut it down first. That's a very fundamental thing to learn. If it's sat there with no screen, keyboard, or mouse attached then that should start making anyone with 2 brain cells turned on think about what it might be there for !As to lead sets again there should be a label do not unplug. It is not good enough to expect people to know the difference between a PC and server.
Meanwhile, back in the real world, most customers won't pay for that. Besides which, I can assure you that having a red plug or anything like that doesn't make the slightest difference to most people. Especially when they get reused for non-important stuff and so having red plugs on anything at all is commonplace.One place I worked all servers had RED plugs which was something of an argument as RED = 400 volt and we wanted BLUE plugs rather than white or black. However the idea of a set colour for special items makes sense and since hospitals and like use RED plugs I suppose red is a standard colour for items not to be unplugged.
Says the man demonstrating a politicians level of knowledge of technical mattersSo virtualise them all, then you can move the VMs and empty the physical server.
Actually, yes it's very common to have dependencies that dictate services need to be started in a set sequence. It's one of the issues we have at work if we have to do a cold start* - some stuff just won't work without other stuff already running. Simple example - if your DNS services aren't running, then anything that needs to resolve names to addresses won't work - and often that means it fails to startup properly.Do they?Often they need switching on in a set order.
Actually, says the man who knows that there are lots of virtualisation solutions out there, and that a large number of them support live migration of VMs.Says the man demonstrating a politicians level of knowledge of technical matters
Sorry - a big chunk of my reply went missing...Actually, yes it's very common to have dependencies that dictate services need to be started in a set sequence.
You shouldn't have any.Thankfully we have very few of those !
So stop digging, then - I am 100% correct that if you virtualise your servers you can move VMs around if you need to empty a server but keep the services running. Along with increased server utilisation the ability to relocate VMs is a major benefit of virtualisation.Sorry BAS, there is a saying that when you are in a hole, stop digging.
No tool will do everything, and no responsible, professional salesperson will claim otherwise.You clearly know the buzzwords, but also clearly don't have practical experience - either that or your identity is revealed as one of those IT tools salesmen who will happily sell your tool as doing all that and more (probably even makes the coffee) but which actually turns out to have a lot of gaps.
I never claimed that there was, of course you'll need to customise it and quite possibly have to write some scripts.Yes, automation tools can help, but mostly (for the general case) they are all custom - our setup isn't the same as other people's, the next guys's setup is different, and so on, so there is no such thing as an off the shelf tool that will do it.
Rare and infrequent, eh?There's a trade-off between how much effort you put into automating a rare event, vs spending that time doing more useful stuff. Or put another way, for the very infrequent times it happens, and the little amount of manual intervention required, it simply isn't a good use of man hours to automate most of it.
Bringing everything up from scratch - which rather embarrassingly we have had to do a number of times.
Someone has been reading the glossy handouts.I am 100% correct that if you virtualise your servers you can move VMs around if you need to empty a server but keep the services running. Along with increased server utilisation the ability to relocate VMs is a major benefit of virtualisation.
In other words, build the tools neededI never claimed that there was, of course you'll need to customise it and quite possibly have to write some scripts.
Assuming they are resolvable. How about resolving this then. A depends on B, B depends on C, B also depends on A, and C also depends (to a lesser extent) on A. The dependencies between A and B aren't negotiable* - B will not start up correctly without A being running, and A will not start up correctly without B running.But even so, automation is beneficial. It enforces a discipline to remove circular dependencies.
No, I change my mind. You're not an IT salesman, it's far far worse than that - you speak like a ... and I feel a bit dirty even using the words ... a management consultantIt builds on rapid provisioning and policy/time-based automation of VM relocation.
Someone knows what the state of the art is.Someone has been reading the glossy handouts.
What do you want? VMware? KVM? Xen? Hyper-V? Oracle VM? HP IVM? IBM PowerVM?Yes, virtualisation may allow VMs to be moved around. It depends on which virtualisation technology
Well, yes - I thought I could take it as read that without all server resources virtualised and without a common storage and network infrastructure shared by source and target then live migration won't work.and what your infrastructure is.
True - it may take more than one click.It's not as simple as "click here, and your VM magically moves" though.
So you've got an infrastructure which cannot cope with unplanned system outages, i.e. no high availability clustering? No DR?Firstly you have to have space for it on the destination - which means having excess capacity which is what virtualisation is (in part) intended to avoid.
No - in other words use the tools to build your environment. What's wrong with you?In other words, build the tools neededI never claimed that there was, of course you'll need to customise it and quite possibly have to write some scripts.
If that were really the case then you could never actually start A or B, if those are services. If they are servers then your physical deployment model is wrong and you need to find the architect responsible for that and break his legs.How about resolving this then. A depends on B, B depends on C, B also depends on A, and C also depends (to a lesser extent) on A. The dependencies between A and B aren't negotiable* - B will not start up correctly without A being running, and A will not start up correctly without B running.
Of course there are, but the whole point of live migration is that things carry on running, and if a VM moves then it moves, and users or other systems using the services it provides also carry on running. A heterogeneous environment dos not prevent VM migration any more than it prevents you manually starting things up. Of course you can't move a Windoze VM to a Linux/HP-UX/AIX server.There are also a shedload of other systems, from disparate vendors, running a variety of operating systems and virtualisation technologies - that is the nature of the beast when you want different systems to be what is appropriate to the job, rather than picking a vendor and shoehorning your requirements into what that vendor provides
Why does it have to be off the shelf? Virtually nothing else is.Having discussed it with others in similar situations, it's clear that there isn't a simple answer - and definitely not one off the shelf.
Neither.No, I change my mind. You're not an IT salesman, it's far far worse than that - you speak like a ... and I feel a bit dirty even using the words ... a management consultant
Indeed, BAS seems to work in a very perfect environment. No-one seems to know what he does, but from his writings here he clearly doesn't actually do this sort of thing. What the glossies say is not the same thing as what happens in real life.So, BAS, it does help but with a total outage (our UPSs running dry) we would face probably around eight hours to get everything restarted. That's the difference between Business Continuity (UPS, virtual farms, load-balancing and failover, etc) and Disaster Recovery (the poo really did hit the fan).
Indeed it is not.Indeed, BAS seems to work in a very perfect environment. No-one seems to know what he does, but from his writings here he clearly doesn't actually do this sort of thing. What the glossies say is not the same thing as what happens in real life.
If you recall my suggestion about virtualising so that you can use live migration to empty a server was in response to the problem of planning a shutdown, not as a way to deal with the problem of a server failure.But of course, this is all a long way away from the original problem of someone yanking a power cord on a server because they were too ignorant to realise that it's not the sort of thing to do.
And I've suggested those things where, exactly?IN that case, the server was exactly the sort of thing where you don't want to virtualise it and put it's storage on your shared storage box. Who on earth (apart from BAS) wants to put their BACKUP data on the same storage as their live data, and be able to switch the VM of the backup to the same box as their live server ?
I didn't say we won't do any of those, but that in the absence of unlimited budgets and unlimited resources, we don't aim for perfection - only what is "reasonable" taking into account all the factors.Indeed it is not.Indeed, BAS seems to work in a very perfect environment. No-one seems to know what he does, but from his writings here he clearly doesn't actually do this sort of thing. What the glossies say is not the same thing as what happens in real life.
So I tell you what then, as real life is imperfect we won't virtualise, we won't automate, and we won't do anything at all to help avoid unplanned outages, be they unplanned, or avoid planned ones.
If you recall my suggestion about virtualising so that you can use live migration to empty a server was in response to the problem of planning a shutdown, not as a way to deal with the problem of a server failure.But of course, this is all a long way away from the original problem of someone yanking a power cord on a server because they were too ignorant to realise that it's not the sort of thing to do.
And I've suggested those things where, exactly?In that case, the server was exactly the sort of thing where you don't want to virtualise it and put it's storage on your shared storage box. Who on earth (apart from BAS) wants to put their BACKUP data on the same storage as their live data, and be able to switch the VM of the backup to the same box as their live server ?
Put forward, it would appear, as a universal answer to any problem requiring a server shutdown. That IS what you appear to have been pushing. You may not have meant that, but it certainly came across that way.So virtualise them all, then you can move the VMs and empty the physical server.Asking people to log off to be able to test is common and with servers finding windows to do work again common. But switching off is still a problem.
I can assure you that you did not start out giving the impression of anything other than implacable opposition to and rejection of those.I didn't say we won't do any of those, but that in the absence of unlimited budgets and unlimited resources, we don't aim for perfection - only what is "reasonable" taking into account all the factors.
That to me, reads as nothing less than an unequivocal rejection of the idea of using the live VM migration facilities offered by many VM managers in order to avoid service outages during planned server shutdowns.Says the man demonstrating a politicians level of knowledge of technical mattersSo virtualise them all, then you can move the VMs and empty the physical server.
I've added some emphasis, as you gave every impression of not having read that part.In that case, if it's a problem, you need an automation/orchestration tool.Actually, yes it's very common to have dependencies that dictate services need to be started in a set sequence.
Sorry BAS, there is a saying that when you are in a hole, stop digging. You clearly know the buzzwords, but also clearly don't have practical experience - either that or your identity is revealed as one of those IT tools salesmen who will happily sell your tool as doing all that and more (probably even makes the coffee) but which actually turns out to have a lot of gaps.
Your answer?And I've suggested those things where, exactly?Who on earth (apart from BAS) wants to put their BACKUP data on the same storage as their live data, and be able to switch the VM of the backup to the same box as their live server ?
So I'll ask you again:Where you wrote :
So virtualise them all, then you can move the VMs and empty the physical server.Asking people to log off to be able to test is common and with servers finding windows to do work again common. But switching off is still a problem.
So I'll ask you again:Where you wrote :
So virtualise them all, then you can move the VMs and empty the physical server.Asking people to log off to be able to test is common and with servers finding windows to do work again common. But switching off is still a problem.
Where have I suggested putting backup data on the same storage as the live data, and where have I suggested moving the VM of the backup to the same box as the live one?
If you need to find a tradesperson to get your job done, please try our local search below, or if you are doing it yourself you can find suppliers local to you.
Select the supplier or trade you require, enter your location to begin your search.
Are you a trade or supplier? You can create your listing free at DIYnot Local