April 7, 2015 at 9:04 am
Eric M Russell (4/7/2015)
If you have some slush money left over in your disaster recovery planning budget, you can play off the fear of executive management by blocking off an entire day to screen 'Zombie Apocalypse' and 'Sharknado 3' in a conference room, inviting the entire DBA team and ordering pizza.
I'm missing "the attack of the killing t:blush:mat:blush:es" from the program
😎
April 7, 2015 at 9:43 am
Eric M Russell (4/7/2015)
Geo-replication and geo-backups are two different things. Every cloud data vendor should have daily or weekly off-site backups that include even the lowest tier customers who arn't paying for geo-replicatation.
Is weekly (or even daily) backup good enough?
Seriously, if your host's datacenter burns down Friday afternoon and their weekly backups are scheduled for Saturday, are you still in business?
The answer, I'm sure, is "it depends on your business". Losing a week of data would be painful, but not fatal for my company (manual recovery of the data is possible in our case). Other company's I've worked with would be bankrupt with a lost week. Either way, I prefer to have a better recovery plan than relying on someone else to probably maybe have week old backups that might be restored sometime soon.
Good Lord! This is simple contingency planning! The Zombie apocalypse probably won't occur, but there are plenty of more mundane things that can take out your systems and you'd better plan for at least a minimum level of disaster recovery. Assuming a hosting company will recover your data completely and in a timely manner is asking for trouble and you'd better have your resume current.
April 7, 2015 at 9:50 am
Brian, you're right on the data level, and maybe overall. The seductive charm of the cloud is you get abstracted from hardware. Even if you have data, you have to have the hardware to run it. If you're cloud based, does it make sense to have a colo based DR plan, or do you rely on the cloud provider to have another site? Can they fail over an entire hosting center and still maintain the SLA for those who failed over and those were already at the alternate site? Totally agree the impact of a week outage varies tremendously.
April 8, 2015 at 9:48 am
Yesterday when I got in to work our internet connection was down, the outage was just under two hours due to an "Emergency power cutoff" at the ISP's facility somewhere.
Last night I received the following email:
At approximately 8 am on April 7th, during a scheduled fire alarm test, the fire suppression system at [university]’s primary data center was inadvertently activated. This activation caused a high pressure release of fire suppression gas that filled the data center. Six [university] employees who were in the data center were evaluated and treated by [university] emergency personnel and one was taken to [local hospital]. All returned to work later in the day.
Activation of the fire suppression system also triggered an immediate interruption of all electrical power to the data center. This resulted in the shutdown of many [university] central computing and networking systems. The abrupt loss of power, coupled with the high pressure release of gas, resulted in damage to some computer and networking equipment.
They're still not completely up according to the last update that I received.
I am not a fan of cloud-based systems, sorry. I'm too old-school: if I can't touch it, I don't want to be responsible for it. Yet it is a growing trend in my current workplace that they want to run hosted systems, and the project that I'm currently developing will be deployed on a hosted VM (that does 2000 IOPS, so performance should be good as small as the system is). I'm planning on capturing all backups to local systems, just in case and for usage analysis. CenturyLink seems to be a good operation for their cloud system, but I won't trust them absolutely.
It may be an alternative to small businesses that can't afford a good IT person, but if they're not aware of the risk of outages and how it can affect them, caveat emptor.
-----
[font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]
April 8, 2015 at 10:23 am
Wayne, I guess what you're saying is that you don't trust your Cloud provider's ISP, because your own local ISP can't be trusted. However, one advantage to geo-location, aside from backups, is to work around regional network outages.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
April 8, 2015 at 10:48 am
Eric M Russell (4/8/2015)
Wayne, I guess what you're saying is that you don't trust your Cloud provider's ISP, because your own local ISP can't be trusted. However, one advantage to geo-location, aside from backups, is to work around regional network outages.
I don't trust them because systems are complicated that they're pretty much guaranteed to break. Google doesn't renew a certificate, Azure has DNS problems or flubs an infrastructure update, AWS is unavailable because it's AWS. We read about cloud outages on a regular basis. If you had a mainframe, you could count on high availability. With SQL Server config you can have hot failover and HA. But if it's in the cloud, you're dependent on what the vendor may or may not be doing, and you have no way of verifying it. Does any cloud/hosted vendor advertise five 9's? I doubt it. There are steps you can take to CYA (cover your assets), but it's still things that you must be proactive with.
The firm Entropy, Finagle and Murphy will always win in the end.
The only way that you can work around an ISP outage is to have your network connected to more than one ISP which apparently we do not have. At least it didn't seriously affect internal operations except connection to our second campus. We're not paying to have my new project spread throughout CenturyLink's cloud because it is not mission critical and is only time critical once a year, once it goes live and we start seeing trends we may rethink that position. If whatever my project is on goes down, some outage is acceptable. We'll see what happens if they have a major outage.
-----
[font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]
April 8, 2015 at 10:52 am
Wayne West wrote:
We read about cloud outages on a regular basis. If you had a mainframe, you could count on high availability.
I have a few stacks of unused punch cards if you need them, Wayne. Just let me know. 😀
April 8, 2015 at 2:16 pm
GoofyGuy (4/8/2015)
Wayne West wrote:We read about cloud outages on a regular basis. If you had a mainframe, you could count on high availability.
I have a few stacks of unused punch cards if you need them, Wayne. Just let me know. 😀
80 or 96 column? I used to be able to read the 80s by sight, but that was a while back. I wouldn't mind some 96's, I bet they'd make great bookmarks. :hehe:
I have some pads of COBOL coding forms sitting around. You never know....
-----
[font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]
April 8, 2015 at 2:27 pm
They're 80 column.
You're welcome to them. I'm not sure they're much good to me. I don't have a punch card machine anymore. :crying:
It's been a while since I wrote any COBOL code; I think the last time was in 1996, working on what even back then was a legacy IBM MVS mainframe.
To my great surprise and pleasure, I discovered shortly thereafter interactive web applications are conceptually similar to CICS, in that both are pseudo-conversational. And I noticed other technical similarities between the two. So web development was my vehicle into 21st Century IT.
Old guys rule.
April 8, 2015 at 2:50 pm
I wrote one COBOL program post-school, must have been about '91. It was a pivot report against our help desk ticketing database on a Wang Pace 7150 or 7310, I don't remember which. The thing that I found awesome was that the instant after you pressed the execute key, the line printer started spitting out paper. I always loved that.
Many fond memories of working in JCL and allocating space and stuff: even though I hate low-level languages (for the most part), I loved working at that level on a mainframe. I occasionally think about picking up a new COBOL book to see the new stuff they've done, but what would I run it on? I think there's a COBOL.net, but it really isn't worth it to satisfy idle curiosity. Maybe I'll look in to it the next time that I have a spell of unemployment.
-----
[font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]
April 8, 2015 at 2:54 pm
Wayne, I think Fujitsu may still offer a PC-based COBOL compiler, although I'm far too lazy to Google it!
I agree, I enjoyed working with JCL, too. I started off with 360/370 assembler which, short of spinning out 0s and 1s, is near to as low-level as one might have gotten back then. It was helpful with macro-level CICS. I loved it all!
But I never got to play with a printer the likes of which you did. Sounds like fun!
April 8, 2015 at 3:23 pm
I hear that Bruce Willis is making a 6th 'Die Hard' movie about an aging night shift security guard at Windows Azure data center that gets held hostage by a group of militant Rastafarians.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
April 8, 2015 at 4:18 pm
As long as he's fighting militant Rastifarians and not Pastafarians, that would hit a little too close to home for me. 😀
I didn't realize it when I saw the last one, Die Hard In Russia, that it was made with foreign distribution in mind and was more successful out of the USA. I thought it rather sucked, but that's just me.
-----
[font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]
April 17, 2015 at 1:32 am
So we need to consider the failing of aspects of SLAs which might be too risky to ignore.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
April 17, 2015 at 7:42 am
Gary Varga (4/17/2015)
So we need to consider the failing of aspects of SLAs which might be too risky to ignore.
Just as the IT department has SLAs with their clients, the cloud data provider should have an SLAs with it's clients. If there are substantial financial penalties for beaking the SLA, then I'm sure the insurance industry will start (if they havn't already) underwriting all this.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
Viewing 15 posts - 31 through 45 (of 66 total)
You must be logged in to reply to this topic. Login to reply