What to do when you don't agree with the opinion of an IT consultant
-
I had a thought earlier today about the lag and stress on the hard drives.
They are constantly scanning PDF's (usually 3 people from 8-5) into the directories while users are trying to access the drives for their data. I wonder if we should be looking to the programmers to code the program to allow our "PDF" files to be on a server that doesn't have the files to run the program. That would free up some hard drive access.
-
@technobabble said:
@alexntg said:
@Nara said:
Was that a consultant, or a Dell rep? Tossing a SAN at something's typically something I see from resellers. From what you've explained, it sounds like you're short on IOPS. With the modern technologies available for localized and distributed tiered storage, SAN wouldn't be the way to go. What's your RTO for these systems?
I smell an opportunity for 3 ESXi hosts and VMWare vSAN, or 2 hosts with flash storage and Veeam cross-host replication.
What? By the way what is the cost of NTG running performance gathering metrics or is this something I can do?
If you can run a Dell DPACK for a 24-hour period over two random days, and get the analysis from Dell, I can take a look at your storage needs and formulate an effective strategy. That'll take about an hour for me to analyze. In the interim, I have a few questions for you:
What's the RPO and RTO for these systems?
What are you using for backup?
What's the projected workload growth percentage on these servers over the next 3 years? -
From the pricing end, that's up to @Minion-Queen
-
RTO and RPO are points I bring up constantly, of course I call it business continuity/disaster planning, which we have none.
I have AM and PM daily backups, which overwrite every few days, using fBackup program.
300%
-
@technobabble said:
RTO and RPO are points I bring up constantly, of course I call it business continuity/disaster planning, which we have none.
I have AM and PM daily backups, which overwrite every few days, using fBackup program.
300%
Until the RPO and RTO can be determined, it's impossible to determine the level of redundancy and backup needed, as well if high availability should come into play. The next step should be to find these things out.
-
I understand. If anything goes down, the company and doctors can't work. However it hasn't happened yet and therefore it is considered back burner stuff. rolling eyes. They provide the program over the internet and yet they still haven't allowed a secondary/backup ISP. We have a dual Wan router ready and waiting for the backup internet connection. Of course if they move to the data center, then it will have the ISP redundancy.
-
Can't work means that you are losing money. But how much is what you have to figure out. A lot, a little. Makes a big difference. And what if a SAN dies?
-
@technobabble said:
I understand. If anything goes down, the company and doctors can't work. However it hasn't happened yet and therefore it is considered back burner stuff. rolling eyes. They provide the program over the internet and yet they still haven't allowed a secondary/backup ISP. We have a dual Wan router ready and waiting for the backup internet connection. Of course if they move to the data center, then it will have the ISP redundancy.
Let me rephrase. I can't go further until I have RPO/RTO info. It's impossible to spec out the appropriate equipment for the project until I know what it needs to be built to. It's a 10-minute conversation that you need to have with management.
-
@alexntg said:
@technobabble said:
I understand. If anything goes down, the company and doctors can't work. However it hasn't happened yet and therefore it is considered back burner stuff. rolling eyes. They provide the program over the internet and yet they still haven't allowed a secondary/backup ISP. We have a dual Wan router ready and waiting for the backup internet connection. Of course if they move to the data center, then it will have the ISP redundancy.
Let me rephrase. I can't go further until I have RPO/RTO info. It's impossible to spec out the appropriate equipment for the project until I know what it needs to be built to. It's a 10-minute conversation that you need to have with management.
Got it. I am waiting for the client to reply.
-
An RPO/RTO question is a lot more difficult to answer than one might expect. I'm sure that Alex and Scott have a linty of questions that can make it easier, but for a company that hasn't ever looked at these questions before it's likely they have no real understanding of how to answer these requests.
When I first started with my company I was told that we could live without our brand new EHR for 6 days (the downtime the vendor told us we'd suffer if we had a total server failure). The vendor at the time refused to provide installation media/files (they built then shipped the servers to us) and all we had for backups were SQL level backups.
I approached the board with a plan to provide better options, but at that near day one the board stated that 6 days of downtime considering the current setup was acceptable. Of course I nearly passed out that this consider I'd been supporting their phones for the past 4 years and they were nearly unbearable when their phones wouldn't sync for a day to their calendars.
Fast forward a year and a few minor outages later, the tune changed and we could now only afford one day of downtime, so they approved the purchase of Appasure, and we reduced our downtime to a few hours.
Back to the point at hand, if the Docs in technobabble's case haven't experienced downtime in the past they will have unrealistic expectations of either uptime or tolerable downtime.
-
Great example of how small businesses think and work. In this case, both Docs and the Billing Company that is providing the Docs the software have never seen data lose nor technical failures. I am drafting a letter to the client to get them thinking about the future of the business.
-
Or the possible lack thereof.
-
@Dashrender said:
An RPO/RTO question is a lot more difficult to answer than one might expect. I'm sure that Alex and Scott have a linty of questions that can make it easier, but for a company that hasn't ever looked at these questions before it's likely they have no real understanding of how to answer these requests.
When I first started with my company I was told that we could live without our brand new EHR for 6 days (the downtime the vendor told us we'd suffer if we had a total server failure). The vendor at the time refused to provide installation media/files (they built then shipped the servers to us) and all we had for backups were SQL level backups.
I approached the board with a plan to provide better options, but at that near day one the board stated that 6 days of downtime considering the current setup was acceptable. Of course I nearly passed out that this consider I'd been supporting their phones for the past 4 years and they were nearly unbearable when their phones wouldn't sync for a day to their calendars.
Fast forward a year and a few minor outages later, the tune changed and we could now only afford one day of downtime, so they approved the purchase of Appasure, and we reduced our downtime to a few hours.
Back to the point at hand, if the Docs in technobabble's case haven't experienced downtime in the past they will have unrealistic expectations of either uptime or tolerable downtime.
For RTO, the easiest way to ask it is, "If X fails, how long can the business be without it before it severely impairs the business?" For some folks, it's a few hours, or even more than a day. For others, it's less. For RPO, it's, "If we need to roll back to backups, how far back can we recover to in an emergency without causing undue data loss?" Most folks are ok with the previous night's backup, but not quite everyone. The longest it's ever taken me to determine RPO/RTO has been about 30 minutes.
-
let me talk to these docs/managers/directors/ whoever
-
Love the community engagement figuring this out, now I'm curious.
Grabs the popcorn
-
A quick conversation with the stakeholders all at one table usually does the trick.
-
The stakeholders are here are just the small business owner.
-
@technobabble said:
The stakeholders are here are just the small business owner.
Should be even easier then.
-
@technobabble said:
The silent partner is becoming involved.
@technobabble said:
The stakeholders are here are just the small business owner.
These two statements do not jive.
-
@JaredBusch said:
@technobabble said:
The silent partner is becoming involved.
@technobabble said:
The stakeholders are here are just the small business owner.
These two statements do not jive.
Crap...you are correct sir, he's not so silent anymore. Thanks to all of you peeps, I was able to bring something new to the table. We'll see if they are interested in protecting their business or just moving servers out of the office.
