Configure Software RAID 1 in Centos
-
@Dashrender said:
Well in RAID 1/10 I suppose the added load today probably isn't an issue for the processor compared to say a RAID 6. But have processors become so powerful that on SMB systems we no longer need to worry about performance drain from doing RAID 6?
That was in 2001!! RAID 7, which uses way more processor power than anything else, is software only! There is no need for SMB to be a factor, RAID has the same load and impact no matter what the environment size. It is the array size that makes the difference and these vary little between company sizes. You've not needed to worry about the "drain" of any RAID level for nearly a decade and a half. And fifteen years ago it was only small Windows-based systems on Intel Pentium II and lower than were an issue. Enterprise servers have always been pure software RAID, even twenty years ago.
-
@scottalanmiller said:
@Dashrender said:
Well in RAID 1/10 I suppose the added load today probably isn't an issue for the processor compared to say a RAID 6. But have processors become so powerful that on SMB systems we no longer need to worry about performance drain from doing RAID 6?
That was in 2001!! RAID 7, which uses way more processor power than anything else, is software only! There is no need for SMB to be a factor, RAID has the same load and impact no matter what the environment size. It is the array size that makes the difference and these vary little between company sizes. You've not needed to worry about the "drain" of any RAID level for nearly a decade and a half. And fifteen years ago it was only small Windows-based systems on Intel Pentium II and lower than were an issue. Enterprise servers have always been pure software RAID, even twenty years ago.
I've never worked on an Enterprise system before - not in my wheelhouse, so I've never seen non hardware RAID systems. I knew it was much less of an issue, but didn't consider it a complete non issue.
-
@scottalanmiller said:
@Dashrender said:
But just because I trust the system doesn't mean everyone does. So doing this test on a system before it goes live in production (but never while in production) isn't unreasonable if the manager wants it.
No, it is very unreasonable. Just because people lack trust doesn't mean that it is reasonable to not trust things. Literally millions of these are in use and have been for decades and work every day. Not trusting this is completely unreasonable and irrational. There are so many places to place your worries that are realistic. Spinning wheels trying to validate an irrational lack of faith in something so insanely well proven is completely unreasonable.
What does testing this once or twice before a company goes live hurt other than setup time/tech time? I'm guessing that after seeing several of these solutions go into place the manager would probably just move on and not require it in the future - but I could be wrong.
-
@Dashrender said:
@scottalanmiller said:
@Dashrender said:
But just because I trust the system doesn't mean everyone does. So doing this test on a system before it goes live in production (but never while in production) isn't unreasonable if the manager wants it.
No, it is very unreasonable. Just because people lack trust doesn't mean that it is reasonable to not trust things. Literally millions of these are in use and have been for decades and work every day. Not trusting this is completely unreasonable and irrational. There are so many places to place your worries that are realistic. Spinning wheels trying to validate an irrational lack of faith in something so insanely well proven is completely unreasonable.
What does testing this once or twice before a company goes live hurt other than setup time/tech time? I'm guessing that after seeing several of these solutions go into place the manager would probably just move on and not require it in the future - but I could be wrong.
Are you going to test it once again after you rebuild the array you now broke? if not what's the guarantee it's still working? It's a endless cycle since you have to break it to check it and you are stating the process over.
-
@thecreativeone91 said:
@Dashrender said:
@scottalanmiller said:
@Dashrender said:
But just because I trust the system doesn't mean everyone does. So doing this test on a system before it goes live in production (but never while in production) isn't unreasonable if the manager wants it.
No, it is very unreasonable. Just because people lack trust doesn't mean that it is reasonable to not trust things. Literally millions of these are in use and have been for decades and work every day. Not trusting this is completely unreasonable and irrational. There are so many places to place your worries that are realistic. Spinning wheels trying to validate an irrational lack of faith in something so insanely well proven is completely unreasonable.
What does testing this once or twice before a company goes live hurt other than setup time/tech time? I'm guessing that after seeing several of these solutions go into place the manager would probably just move on and not require it in the future - but I could be wrong.
Are you going to test it once again after you rebuild the array you now broke? if not what's the guarantee it's still working? It's a endless cycle since you have to break it to check it and you are stating the process over.
Of course not, and while I see your point, it's a cyclical thing - but for someone who is unfamiliar with the system, if they want to prove it to themselves once before production, I don't see the harm. But if I was their IT team, after showing this manager 2 or 3 times (different servers) I would have another conversation with them about dropping this need, since he's been shown the technology works and needs to be trusted on it's own merit.
-
@Dashrender said:
@scottalanmiller said:
@Dashrender said:
But just because I trust the system doesn't mean everyone does. So doing this test on a system before it goes live in production (but never while in production) isn't unreasonable if the manager wants it.
No, it is very unreasonable. Just because people lack trust doesn't mean that it is reasonable to not trust things. Literally millions of these are in use and have been for decades and work every day. Not trusting this is completely unreasonable and irrational. There are so many places to place your worries that are realistic. Spinning wheels trying to validate an irrational lack of faith in something so insanely well proven is completely unreasonable.
What does testing this once or twice before a company goes live hurt other than setup time/tech time? I'm guessing that after seeing several of these solutions go into place the manager would probably just move on and not require it in the future - but I could be wrong.
As long as you are doing it ONLY before... you are only wasting time, not really hurting anything. But it is a process that cannot continue to a live system.
-
@Dashrender said:
I've never worked on an Enterprise system before - not in my wheelhouse, so I've never seen non hardware RAID systems. I knew it was much less of an issue, but didn't consider it a complete non issue.
Pretty much the entire NAS and SAN space is software RAID. You see it all the time and don't realize it, I'm sure.
-
@Dashrender said:
@thecreativeone91 said:
@Dashrender said:
@scottalanmiller said:
@Dashrender said:
But just because I trust the system doesn't mean everyone does. So doing this test on a system before it goes live in production (but never while in production) isn't unreasonable if the manager wants it.
No, it is very unreasonable. Just because people lack trust doesn't mean that it is reasonable to not trust things. Literally millions of these are in use and have been for decades and work every day. Not trusting this is completely unreasonable and irrational. There are so many places to place your worries that are realistic. Spinning wheels trying to validate an irrational lack of faith in something so insanely well proven is completely unreasonable.
What does testing this once or twice before a company goes live hurt other than setup time/tech time? I'm guessing that after seeing several of these solutions go into place the manager would probably just move on and not require it in the future - but I could be wrong.
Are you going to test it once again after you rebuild the array you now broke? if not what's the guarantee it's still working? It's a endless cycle since you have to break it to check it and you are stating the process over.
Of course not, and while I see your point, it's a cyclical thing - but for someone who is unfamiliar with the system, if they want to prove it to themselves once before production, I don't see the harm. But if I was their IT team, after showing this manager 2 or 3 times (different servers) I would have another conversation with them about dropping this need, since he's been shown the technology works and needs to be trusted on it's own merit.
If a manager has never seen RAID you have much, much bigger issues.
-
@scottalanmiller said:
@Dashrender said:
@scottalanmiller said:
@Dashrender said:
But just because I trust the system doesn't mean everyone does. So doing this test on a system before it goes live in production (but never while in production) isn't unreasonable if the manager wants it.
No, it is very unreasonable. Just because people lack trust doesn't mean that it is reasonable to not trust things. Literally millions of these are in use and have been for decades and work every day. Not trusting this is completely unreasonable and irrational. There are so many places to place your worries that are realistic. Spinning wheels trying to validate an irrational lack of faith in something so insanely well proven is completely unreasonable.
What does testing this once or twice before a company goes live hurt other than setup time/tech time? I'm guessing that after seeing several of these solutions go into place the manager would probably just move on and not require it in the future - but I could be wrong.
As long as you are doing it ONLY before... you are only wasting time, not really hurting anything. But it is a process that cannot continue to a live system.
I completely agree- doing it once the system is in production is reckless and dangerous!
-
@scottalanmiller said:
@Dashrender said:
I've never worked on an Enterprise system before - not in my wheelhouse, so I've never seen non hardware RAID systems. I knew it was much less of an issue, but didn't consider it a complete non issue.
Pretty much the entire NAS and SAN space is software RAID. You see it all the time and don't realize it, I'm sure.
We don't have any of these either - so you're right I haven't been exposed.
Do the small Buffalo and others do RAID all in software? it's not in the hardware within the drive enclosure?
-
@Dashrender said:
Do the small Buffalo and others do RAID all in software? it's not in the hardware within the drive enclosure?
Correct. All of them. Buffalo, QNAP, Synology, ReadyNAS, ReadyDATA, Drobo, Thecus, Seagate, Western Digital, etc. Everything in that category is software RAID. Some of them, like ReadyDATA, specifically are sold based on the software RAID itself (the selling points of the ReadyDATA over the ReadyNAS is in the software RAID!)
In the bigger space you get a mix of software and hardware. So NetApp, I believe, uses an ASIC. But they also do a RAID level not available in standard software RAID from any RAID vendor, so they had to do something special anyway.
-
Interesting, thanks.
