One thing that I have always thought about with SVM root vol protection is, if it is an operational recommendation, why aren’t they automatically created in a System Manager workflow when a NAS SVM is created? Things to make you say, Hmmmmmmmn
From: Scott M Gelb via Toasters toasters@teaparty.net toasters@teaparty.net Reply: Scott M Gelb scottgelb@yahoo.com scottgelb@yahoo.com Date: April 28, 2021 at 16:46:47 To: Parisi, Justin justin.parisi@netapp.com justin.parisi@netapp.com, John Stoffel john@stoffel.org john@stoffel.org Cc: toasters@teaparty.net toasters@teaparty.net toasters@teaparty.net Subject:
I have used both DP and LS over the years and am back to using LS more often for reasons Justin wrote, and also for an NAE/NVE workaround where DP make-vsroot had some hoops to jump through to re-create the mirrors after a failover test. LS mirror promote and recreate after had no issues with NAE/NVE in my testing. In all the years doing this, I've never had to recover svm root, but to follow best practices for NAS, still implement them. I don't create mirrors on all nodes and use 1-2 copies depending on cluster size.
An interesting test in mirror activation, is that the mirror picks up the existing SVM junctions regardless of the state of SVM root mirror. For example:
1) An SVM has 4 junction paths 2) SVM root mirror LS or DP to protect SVM root 3) unmount 3 of the junction paths leaving 1 junction path 4) failover to the root mirror (promote LS or break/make-vsroot DP) 5) SVM root running on the failed over volume has the 1 junction path, not the 4 that existed at the time of the mirror... there was no real failure, and the procedure with the SVM running keeps the current state. If a real disaster, I would expect recovery to what was in the mirror, but have never had to recover svm root.
An RFE on my wish list is to have the SVM root virtualized in the RDB, then we don't need to manage, replicate or ever move SVM root. I know this isn't an easy task and would use mroot/vol0, and cause more cluster traffic, but still would welcome seeing a change to do this if feasible. Not a show stopper or requirement, nor high priority.
On Wednesday, April 28, 2021, 11:24:12 AM PDT, John Stoffel < john@stoffel.org> wrote:
Justin> Another pretty major difference between LS and DP methods; Justin> DP method requires manual intervention when a failover/restore is needed.
This is fine in my case, because I'm really trying to protect against a shipping failure, though it's tempting to do more to protect against root volume failures as well. Though I've honestly never had one, nor had a netapp fail so badly in 22+ years of using them that I lost data from hardware failures.
Closest I came was on a F740 (I think) using the DEC StorageWorks canisters and shelves. I had a two disk failure in an aggregate. One disk you could hear scrapping the heads on the platter, the other was a controller board failure. Since I had nothing to lose, I took the good controller board off the head crash drive and put it onto the other disk. System came up and found the data and started rebuilding. Whew! Raid-DP is a good thing today for sure.
Justin> LS Mirrors are running in parallel and incoming reads/access Justin> requests (other than NFSv4) hit the LS mirrors rather than the Justin> source volume, so if one fails, you don’t have to do anything Justin> right away; you’d just need to resolve the issue at some Justin> point, but no interruption to service.
That's a decent reason to use them.
Justin> LS mirrors can also have a schedule to run to avoid needing to Justin> update them regularly. And, if you need to write to the SVM Justin> root for some reason, you’d need to access the .admin path in Justin> the vsroot; LS mirrors are readonly (like DP mirrors).
The default for 9.3 seems to be 1 hour, but I bumped it to every 5 minutes, because I have Netbackup backups which use snapshots and 'vol clone ...' to mount Oracle volumes for backups. I had to hack my backuppolicy.sh script to put in a 'sleep 305' to make it work properly.
Trying to make it work generically with 'snapmirror update-ls-set <vserver>:<source>' wasn't working for some reason, so the quick hack of a sleep got me working.
But I am thinking of dropping the LS mirrors and just going with DP mirrors of all my rootvols instead, just because of this issue.
But let's do a survey, how many people on here are using LS mirrors of your rootvols on your clusters? I certainly wasn't across multiple clusters.
Jhn
_______________________________________________ Toasters mailing list Toasters@teaparty.net https://www.teaparty.net/mailman/listinfo/toasters _______________________________________________ Toasters mailing list Toasters@teaparty.net https://www.teaparty.net/mailman/listinfo/toasters
Andre - I second that.... especially after all this time.
On Fri, Apr 30, 2021 at 9:22 AM André M. Clark andre.m.clark@gmail.com wrote:
One thing that I have always thought about with SVM root vol protection is, if it is an operational recommendation, why aren’t they automatically created in a System Manager workflow when a NAS SVM is created? Things to make you say, Hmmmmmmmn
From: Scott M Gelb via Toasters toasters@teaparty.net toasters@teaparty.net Reply: Scott M Gelb scottgelb@yahoo.com scottgelb@yahoo.com Date: April 28, 2021 at 16:46:47 To: Parisi, Justin justin.parisi@netapp.com justin.parisi@netapp.com, John Stoffel john@stoffel.org john@stoffel.org Cc: toasters@teaparty.net toasters@teaparty.net toasters@teaparty.net Subject:
I have used both DP and LS over the years and am back to using LS more often for reasons Justin wrote, and also for an NAE/NVE workaround where DP make-vsroot had some hoops to jump through to re-create the mirrors after a failover test. LS mirror promote and recreate after had no issues with NAE/NVE in my testing. In all the years doing this, I've never had to recover svm root, but to follow best practices for NAS, still implement them. I don't create mirrors on all nodes and use 1-2 copies depending on cluster size.
An interesting test in mirror activation, is that the mirror picks up the existing SVM junctions regardless of the state of SVM root mirror. For example:
- An SVM has 4 junction paths
- SVM root mirror LS or DP to protect SVM root
- unmount 3 of the junction paths leaving 1 junction path
- failover to the root mirror (promote LS or break/make-vsroot DP)
- SVM root running on the failed over volume has the 1 junction path, not
the 4 that existed at the time of the mirror... there was no real failure, and the procedure with the SVM running keeps the current state. If a real disaster, I would expect recovery to what was in the mirror, but have never had to recover svm root.
An RFE on my wish list is to have the SVM root virtualized in the RDB, then we don't need to manage, replicate or ever move SVM root. I know this isn't an easy task and would use mroot/vol0, and cause more cluster traffic, but still would welcome seeing a change to do this if feasible. Not a show stopper or requirement, nor high priority.
On Wednesday, April 28, 2021, 11:24:12 AM PDT, John Stoffel < john@stoffel.org> wrote:
Justin> Another pretty major difference between LS and DP methods; Justin> DP method requires manual intervention when a failover/restore is needed.
This is fine in my case, because I'm really trying to protect against a shipping failure, though it's tempting to do more to protect against root volume failures as well. Though I've honestly never had one, nor had a netapp fail so badly in 22+ years of using them that I lost data from hardware failures.
Closest I came was on a F740 (I think) using the DEC StorageWorks canisters and shelves. I had a two disk failure in an aggregate. One disk you could hear scrapping the heads on the platter, the other was a controller board failure. Since I had nothing to lose, I took the good controller board off the head crash drive and put it onto the other disk. System came up and found the data and started rebuilding. Whew! Raid-DP is a good thing today for sure.
Justin> LS Mirrors are running in parallel and incoming reads/access Justin> requests (other than NFSv4) hit the LS mirrors rather than the Justin> source volume, so if one fails, you don’t have to do anything Justin> right away; you’d just need to resolve the issue at some Justin> point, but no interruption to service.
That's a decent reason to use them.
Justin> LS mirrors can also have a schedule to run to avoid needing to Justin> update them regularly. And, if you need to write to the SVM Justin> root for some reason, you’d need to access the .admin path in Justin> the vsroot; LS mirrors are readonly (like DP mirrors).
The default for 9.3 seems to be 1 hour, but I bumped it to every 5 minutes, because I have Netbackup backups which use snapshots and 'vol clone ...' to mount Oracle volumes for backups. I had to hack my backuppolicy.sh script to put in a 'sleep 305' to make it work properly.
Trying to make it work generically with 'snapmirror update-ls-set <vserver>:<source>' wasn't working for some reason, so the quick hack of a sleep got me working.
But I am thinking of dropping the LS mirrors and just going with DP mirrors of all my rootvols instead, just because of this issue.
But let's do a survey, how many people on here are using LS mirrors of your rootvols on your clusters? I certainly wasn't across multiple clusters.
Jhn
Toasters mailing list Toasters@teaparty.net https://www.teaparty.net/mailman/listinfo/toasters _______________________________________________ Toasters mailing list Toasters@teaparty.net https://www.teaparty.net/mailman/listinfo/toasters
Toasters mailing list Toasters@teaparty.net https://www.teaparty.net/mailman/listinfo/toasters
Yeah it’s interesting that they aren’t created automatically.
It could have something to do with issues it causes. Especially if you are using SRM \ SRA within an NFS VMWare environment.
Chris
From: Toasters toasters-bounces@teaparty.net On Behalf Of André M. Clark Sent: 30 April 2021 14:20 To: Scott M Gelb scottgelb@yahoo.com; Parisi, Justin justin.parisi@netapp.com; Scott M Gelb via Toasters toasters@teaparty.net; John Stoffel john@stoffel.org Subject: Re:
[EXTERNAL]
One thing that I have always thought about with SVM root vol protection is, if it is an operational recommendation, why aren’t they automatically created in a System Manager workflow when a NAS SVM is created? Things to make you say, Hmmmmmmmn
From: Scott M Gelb via Toasters toasters@teaparty.netmailto:toasters@teaparty.net Reply: Scott M Gelb scottgelb@yahoo.commailto:scottgelb@yahoo.com Date: April 28, 2021 at 16:46:47 To: Parisi, Justin justin.parisi@netapp.commailto:justin.parisi@netapp.com, John Stoffel john@stoffel.orgmailto:john@stoffel.org Cc: toasters@teaparty.netmailto:toasters@teaparty.net toasters@teaparty.netmailto:toasters@teaparty.net Subject:
I have used both DP and LS over the years and am back to using LS more often for reasons Justin wrote, and also for an NAE/NVE workaround where DP make-vsroot had some hoops to jump through to re-create the mirrors after a failover test. LS mirror promote and recreate after had no issues with NAE/NVE in my testing. In all the years doing this, I've never had to recover svm root, but to follow best practices for NAS, still implement them. I don't create mirrors on all nodes and use 1-2 copies depending on cluster size.
An interesting test in mirror activation, is that the mirror picks up the existing SVM junctions regardless of the state of SVM root mirror. For example:
1) An SVM has 4 junction paths 2) SVM root mirror LS or DP to protect SVM root 3) unmount 3 of the junction paths leaving 1 junction path 4) failover to the root mirror (promote LS or break/make-vsroot DP) 5) SVM root running on the failed over volume has the 1 junction path, not the 4 that existed at the time of the mirror... there was no real failure, and the procedure with the SVM running keeps the current state. If a real disaster, I would expect recovery to what was in the mirror, but have never had to recover svm root.
An RFE on my wish list is to have the SVM root virtualized in the RDB, then we don't need to manage, replicate or ever move SVM root. I know this isn't an easy task and would use mroot/vol0, and cause more cluster traffic, but still would welcome seeing a change to do this if feasible. Not a show stopper or requirement, nor high priority.
On Wednesday, April 28, 2021, 11:24:12 AM PDT, John Stoffel <john@stoffel.orgmailto:john@stoffel.org> wrote:
Justin> Another pretty major difference between LS and DP methods; Justin> DP method requires manual intervention when a failover/restore is needed.
This is fine in my case, because I'm really trying to protect against a shipping failure, though it's tempting to do more to protect against root volume failures as well. Though I've honestly never had one, nor had a netapp fail so badly in 22+ years of using them that I lost data from hardware failures.
Closest I came was on a F740 (I think) using the DEC StorageWorks canisters and shelves. I had a two disk failure in an aggregate. One disk you could hear scrapping the heads on the platter, the other was a controller board failure. Since I had nothing to lose, I took the good controller board off the head crash drive and put it onto the other disk. System came up and found the data and started rebuilding. Whew! Raid-DP is a good thing today for sure.
Justin> LS Mirrors are running in parallel and incoming reads/access Justin> requests (other than NFSv4) hit the LS mirrors rather than the Justin> source volume, so if one fails, you don’t have to do anything Justin> right away; you’d just need to resolve the issue at some Justin> point, but no interruption to service.
That's a decent reason to use them.
Justin> LS mirrors can also have a schedule to run to avoid needing to Justin> update them regularly. And, if you need to write to the SVM Justin> root for some reason, you’d need to access the .admin path in Justin> the vsroot; LS mirrors are readonly (like DP mirrors).
The default for 9.3 seems to be 1 hour, but I bumped it to every 5 minutes, because I have Netbackup backups which use snapshots and 'vol clone ...' to mount Oracle volumes for backups. I had to hack my backuppolicy.sh script to put in a 'sleep 305' to make it work properly.
Trying to make it work generically with 'snapmirror update-ls-set <vserver>:<source>' wasn't working for some reason, so the quick hack of a sleep got me working.
But I am thinking of dropping the LS mirrors and just going with DP mirrors of all my rootvols instead, just because of this issue.
But let's do a survey, how many people on here are using LS mirrors of your rootvols on your clusters? I certainly wasn't across multiple clusters.
Jhn
_______________________________________________ Toasters mailing list Toasters@teaparty.netmailto:Toasters@teaparty.net https://www.teaparty.net/mailman/listinfo/toastershttps://clicktime.symantec.com/3Mv9ujoNQEkcpi63Sctndn57Vc?u=https%3A%2F%2Fwww.teaparty.net%2Fmailman%2Flistinfo%2Ftoasters _______________________________________________ Toasters mailing list Toasters@teaparty.netmailto:Toasters@teaparty.net https://www.teaparty.net/mailman/listinfo/toastershttps://clicktime.symantec.com/3Mv9ujoNQEkcpi63Sctndn57Vc?u=https%3A%2F%2Fwww.teaparty.net%2Fmailman%2Flistinfo%2Ftoasters
This email is being sent by a subsidiary of Arthur J. Gallagher Holdings (UK) Limited, part of the Arthur J. Gallagher & Co. global group of companies. For details of the registered office, company number and, where applicable, regulated status of our subsidiaries, please visit https://www.ajginternational.com/legal-regulatory-information/.
We are the data controller of any personal information you provide to us or personal information that has been provided to us by a third party. We collect and process information about you in order to arrange insurance policies and to process claims. Your information is also used for business purposes such as fraud prevention and detection and financial management. This may involve sharing your information with third parties such as insurers, reinsurers, other brokers, claims handlers, loss adjusters, credit reference agencies, service providers, professional advisors, our regulators, police and government agencies or fraud prevention agencies.
We may record telephone calls to help us monitor and improve the service we provide. For further information on how your information is used and your rights in relation to your information please see our privacy notice at https://www.ajginternational.com/Privacy-Policy/. If you are providing personal data of another individual to us, you must tell them you are providing their information to us and show them a copy of this notice.
Where you are obtaining a non-consumer policy of (re)insurance, or cover for additional risks or renewal under an existing policy, you are required to make a fair presentation of the risk to a (re)insurer which discloses every material circumstance which you know or ought to know relating to the risk to be insured. A circumstance is material if it would influence the judgment of a prudent insurer in determining whether to provide insurance for the risk and, if so, on what terms. Disclosure must be reasonably clear and accessible to a prudent insurer and made in good faith. The aforementioned duty of disclosure is the applicable duty under the laws of England and Wales. If your policy is not subject to English law you are expected to disclose risk information in accordance with the requirements of the applicable law. In such circumstances we expect you will disclose risk information at least equal to the standard required under English law and where the applicable law requires you to disclose information over and above the level required under English law you will provide such information in accordance with that law.
Where you are obtaining a consumer policy of insurance, you must read each question and answer honestly and fully and must take reasonable care to not make a misrepresentation.
Failure to comply with the above disclosure requirements, as they apply to you, could mean that your policy of (re)insurance is void, its terms are materially altered or that (re)insurers are not liable to pay all or part of your claim(s). If you are in any doubt as to your obligations you should ask your usual contact.
This e-mail and any attachments are CONFIDENTIAL and may contain legally privileged information. If you are not the intended recipient of this e-mail message, please telephone or e-mail us immediately, delete this message from your system and do not read, copy, distribute, disclose or otherwise use this e-mail message and any attachments. Although the above company has taken reasonable precautions to ensure this e-mail and any attachments are free of any virus or other defect that may affect your computer, it is the responsibility of the recipient to ensure that it is virus free and the above company does not accept any responsibility for any loss or damage arising in any way from its use.
"Chris" == Chris Hague Chris_Hague@ajg.com writes:
Chris> Yeah it’s interesting that they aren’t created automatically.
Chris> It could have something to do with issues it causes. Especially Chris> if you are using SRM \ SRA within an NFS VMWare environment.
We're using ESX NFS datastores, so now I'm wondering if I've potentially screwed myself over at some point.
It might just be smarter to make snapmirrors of my various VServer rootvols instead. It's not like I've ever had any performance issues with my rootvols, and now I have to wait 5 minutes for changes (vol clone... vol mount ...) to take effect, or push the updates manually.
I honestly think this is a poor design which could be improved.
John
Chris> From: Toasters toasters-bounces@teaparty.net On Behalf Of André M. Clark Chris> Sent: 30 April 2021 14:20 Chris> To: Scott M Gelb scottgelb@yahoo.com; Parisi, Justin justin.parisi@netapp.com; Scott M Gelb Chris> via Toasters toasters@teaparty.net; John Stoffel john@stoffel.org Chris> Subject: Re:
Chris> [EXTERNAL]
Chris> One thing that I have always thought about with SVM root vol protection is, if it is an Chris> operational recommendation, why aren’t they automatically created in a System Manager workflow Chris> when a NAS SVM is created? Things to make you say, Hmmmmmmmn
Chris> From: Scott M Gelb via Toasters toasters@teaparty.net Chris> Reply: Scott M Gelb scottgelb@yahoo.com Chris> Date: April 28, 2021 at 16:46:47 Chris> To: Parisi, Justin justin.parisi@netapp.com, John Stoffel john@stoffel.org Chris> Cc: toasters@teaparty.net toasters@teaparty.net Chris> Subject:
Chris> I have used both DP and LS over the years and am back to using LS more often for reasons Chris> Justin wrote, and also for an NAE/NVE workaround where DP make-vsroot had some hoops to jump Chris> through to re-create the mirrors after a failover test. LS mirror promote and recreate after Chris> had no issues with NAE/NVE in my testing. In all the years doing this, I've never had to Chris> recover svm root, but to follow best practices for NAS, still implement them. I don't create Chris> mirrors on all nodes and use 1-2 copies depending on cluster size.
Chris> An interesting test in mirror activation, is that the mirror picks up the existing SVM Chris> junctions regardless of the state of SVM root mirror. For example:
Chris> 1) An SVM has 4 junction paths
Chris> 2) SVM root mirror LS or DP to protect SVM root
Chris> 3) unmount 3 of the junction paths leaving 1 junction path
Chris> 4) failover to the root mirror (promote LS or break/make-vsroot DP)
Chris> 5) SVM root running on the failed over volume has the 1 junction path, not the 4 that Chris> existed at the time of the mirror... there was no real failure, and the procedure with the Chris> SVM running keeps the current state. If a real disaster, I would expect recovery to what Chris> was in the mirror, but have never had to recover svm root.
Chris> An RFE on my wish list is to have the SVM root virtualized in the RDB, then we don't need to Chris> manage, replicate or ever move SVM root. I know this isn't an easy task and would use mroot/ Chris> vol0, and cause more cluster traffic, but still would welcome seeing a change to do this if Chris> feasible. Not a show stopper or requirement, nor high priority.
Chris> On Wednesday, April 28, 2021, 11:24:12 AM PDT, John Stoffel john@stoffel.org wrote:
Justin> Another pretty major difference between LS and DP methods; Justin> DP method requires manual intervention when a failover/restore is needed.
Chris> This is fine in my case, because I'm really trying to protect against Chris> a shipping failure, though it's tempting to do more to protect against Chris> root volume failures as well. Though I've honestly never had one, nor Chris> had a netapp fail so badly in 22+ years of using them that I lost data Chris> from hardware failures.
Chris> Closest I came was on a F740 (I think) using the DEC StorageWorks Chris> canisters and shelves. I had a two disk failure in an aggregate. One Chris> disk you could hear scrapping the heads on the platter, the other was Chris> a controller board failure. Since I had nothing to lose, I took the Chris> good controller board off the head crash drive and put it onto the Chris> other disk. System came up and found the data and started Chris> rebuilding. Whew! Raid-DP is a good thing today for sure.
Justin> LS Mirrors are running in parallel and incoming reads/access Justin> requests (other than NFSv4) hit the LS mirrors rather than the Justin> source volume, so if one fails, you don’t have to do anything Justin> right away; you’d just need to resolve the issue at some Justin> point, but no interruption to service.
Chris> That's a decent reason to use them.
Justin> LS mirrors can also have a schedule to run to avoid needing to Justin> update them regularly. And, if you need to write to the SVM Justin> root for some reason, you’d need to access the .admin path in Justin> the vsroot; LS mirrors are readonly (like DP mirrors).
Chris> The default for 9.3 seems to be 1 hour, but I bumped it to every 5 Chris> minutes, because I have Netbackup backups which use snapshots and 'vol Chris> clone ...' to mount Oracle volumes for backups. I had to hack my Chris> backuppolicy.sh script to put in a 'sleep 305' to make it work Chris> properly.
Chris> Trying to make it work generically with 'snapmirror update-ls-set Chris> <vserver>:<source>' wasn't working for some reason, so the quick hack Chris> of a sleep got me working.
Chris> But I am thinking of dropping the LS mirrors and just going with DP Chris> mirrors of all my rootvols instead, just because of this issue.
Chris> But let's do a survey, how many people on here are using LS mirrors of Chris> your rootvols on your clusters? I certainly wasn't across multiple Chris> clusters.
Chris> Jhn
Chris> _______________________________________________ Chris> Toasters mailing list Chris> Toasters@teaparty.net Chris> https://www.teaparty.net/mailman/listinfo/toasters
Chris> _______________________________________________ Chris> Toasters mailing list Chris> Toasters@teaparty.net Chris> https://www.teaparty.net/mailman/listinfo/toasters
Chris> This email is being sent by a subsidiary of Arthur J. Gallagher Holdings (UK) Limited, part of the Chris> Arthur J. Gallagher & Co. global group of companies. For details of the registered office, company Chris> number and, where applicable, regulated status of our subsidiaries, please visit Chris> https://www.ajginternational.com/legal-regulatory-information/.
Chris> We are the data controller of any personal information you provide to us or personal information Chris> that has been provided to us by a third party. We collect and process information about you in Chris> order to arrange insurance policies and to process claims. Your information is also used for Chris> business purposes such as fraud prevention and detection and financial management. This may Chris> involve sharing your information with third parties such as insurers, reinsurers, other brokers, Chris> claims handlers, loss adjusters, credit reference agencies, service providers, professional Chris> advisors, our regulators, police and government agencies or fraud prevention agencies.
Chris> We may record telephone calls to help us monitor and improve the service we provide. For further Chris> information on how your information is used and your rights in relation to your information please Chris> see our privacy notice at https://www.ajginternational.com/Privacy-Policy/. If you are providing Chris> personal data of another individual to us, you must tell them you are providing their information Chris> to us and show them a copy of this notice.
Chris> Where you are obtaining a non-consumer policy of (re)insurance, or cover for additional risks or Chris> renewal under an existing policy, you are required to make a fair presentation of the risk to a Chris> (re)insurer which discloses every material circumstance which you know or ought to know relating Chris> to the risk to be insured. A circumstance is material if it would influence the judgment of a Chris> prudent insurer in determining whether to provide insurance for the risk and, if so, on what Chris> terms. Disclosure must be reasonably clear and accessible to a prudent insurer and made in good Chris> faith. The aforementioned duty of disclosure is the applicable duty under the laws of England and Chris> Wales. If your policy is not subject to English law you are expected to disclose risk information Chris> in accordance with the requirements of the applicable law. In such circumstances we expect you Chris> will disclose risk information at least equal to the standard required under English law and where Chris> the applicable law requires you to disclose information over and above the level required under Chris> English law you will provide such information in accordance with that law.
Chris> Where you are obtaining a consumer policy of insurance, you must read each question and answer Chris> honestly and fully and must take reasonable care to not make a misrepresentation.
Chris> Failure to comply with the above disclosure requirements, as they apply to you, could mean that Chris> your policy of (re)insurance is void, its terms are materially altered or that (re)insurers are Chris> not liable to pay all or part of your claim(s). If you are in any doubt as to your obligations you Chris> should ask your usual contact.
Chris> This e-mail and any attachments are CONFIDENTIAL and may contain legally privileged information. Chris> If you are not the intended recipient of this e-mail message, please telephone or e-mail us Chris> immediately, delete this message from your system and do not read, copy, distribute, disclose or Chris> otherwise use this e-mail message and any attachments. Although the above company has taken Chris> reasonable precautions to ensure this e-mail and any attachments are free of any virus or other Chris> defect that may affect your computer, it is the responsibility of the recipient to ensure that it Chris> is virus free and the above company does not accept any responsibility for any loss or damage Chris> arising in any way from its use.
If I recall, I’d you utilize the ontap tools like vsc or otv they automatically spare the mirror after making a volume for Vmware!
Get Outlook for iOShttps://aka.ms/o0ukef ________________________________ From: Toasters toasters-bounces@teaparty.net on behalf of John Stoffel john@stoffel.org Sent: Saturday, May 1, 2021 2:43:50 PM To: Chris Hague Chris_Hague@ajg.com Cc: Scott M Gelb via Toasters toasters@teaparty.net Subject: RE: Re:
"Chris" == Chris Hague Chris_Hague@ajg.com writes:
Chris> Yeah it’s interesting that they aren’t created automatically.
Chris> It could have something to do with issues it causes. Especially Chris> if you are using SRM \ SRA within an NFS VMWare environment.
We're using ESX NFS datastores, so now I'm wondering if I've potentially screwed myself over at some point.
It might just be smarter to make snapmirrors of my various VServer rootvols instead. It's not like I've ever had any performance issues with my rootvols, and now I have to wait 5 minutes for changes (vol clone... vol mount ...) to take effect, or push the updates manually.
I honestly think this is a poor design which could be improved.
John
Chris> From: Toasters toasters-bounces@teaparty.net On Behalf Of André M. Clark Chris> Sent: 30 April 2021 14:20 Chris> To: Scott M Gelb scottgelb@yahoo.com; Parisi, Justin justin.parisi@netapp.com; Scott M Gelb Chris> via Toasters toasters@teaparty.net; John Stoffel john@stoffel.org Chris> Subject: Re:
Chris> [EXTERNAL]
Chris> One thing that I have always thought about with SVM root vol protection is, if it is an Chris> operational recommendation, why aren’t they automatically created in a System Manager workflow Chris> when a NAS SVM is created? Things to make you say, Hmmmmmmmn
Chris> From: Scott M Gelb via Toasters toasters@teaparty.net Chris> Reply: Scott M Gelb scottgelb@yahoo.com Chris> Date: April 28, 2021 at 16:46:47 Chris> To: Parisi, Justin justin.parisi@netapp.com, John Stoffel john@stoffel.org Chris> Cc: toasters@teaparty.net toasters@teaparty.net Chris> Subject:
Chris> I have used both DP and LS over the years and am back to using LS more often for reasons Chris> Justin wrote, and also for an NAE/NVE workaround where DP make-vsroot had some hoops to jump Chris> through to re-create the mirrors after a failover test. LS mirror promote and recreate after Chris> had no issues with NAE/NVE in my testing. In all the years doing this, I've never had to Chris> recover svm root, but to follow best practices for NAS, still implement them. I don't create Chris> mirrors on all nodes and use 1-2 copies depending on cluster size.
Chris> An interesting test in mirror activation, is that the mirror picks up the existing SVM Chris> junctions regardless of the state of SVM root mirror. For example:
Chris> 1) An SVM has 4 junction paths
Chris> 2) SVM root mirror LS or DP to protect SVM root
Chris> 3) unmount 3 of the junction paths leaving 1 junction path
Chris> 4) failover to the root mirror (promote LS or break/make-vsroot DP)
Chris> 5) SVM root running on the failed over volume has the 1 junction path, not the 4 that Chris> existed at the time of the mirror... there was no real failure, and the procedure with the Chris> SVM running keeps the current state. If a real disaster, I would expect recovery to what Chris> was in the mirror, but have never had to recover svm root.
Chris> An RFE on my wish list is to have the SVM root virtualized in the RDB, then we don't need to Chris> manage, replicate or ever move SVM root. I know this isn't an easy task and would use mroot/ Chris> vol0, and cause more cluster traffic, but still would welcome seeing a change to do this if Chris> feasible. Not a show stopper or requirement, nor high priority.
Chris> On Wednesday, April 28, 2021, 11:24:12 AM PDT, John Stoffel john@stoffel.org wrote:
Justin> Another pretty major difference between LS and DP methods; Justin> DP method requires manual intervention when a failover/restore is needed.
Chris> This is fine in my case, because I'm really trying to protect against Chris> a shipping failure, though it's tempting to do more to protect against Chris> root volume failures as well. Though I've honestly never had one, nor Chris> had a netapp fail so badly in 22+ years of using them that I lost data Chris> from hardware failures.
Chris> Closest I came was on a F740 (I think) using the DEC StorageWorks Chris> canisters and shelves. I had a two disk failure in an aggregate. One Chris> disk you could hear scrapping the heads on the platter, the other was Chris> a controller board failure. Since I had nothing to lose, I took the Chris> good controller board off the head crash drive and put it onto the Chris> other disk. System came up and found the data and started Chris> rebuilding. Whew! Raid-DP is a good thing today for sure.
Justin> LS Mirrors are running in parallel and incoming reads/access Justin> requests (other than NFSv4) hit the LS mirrors rather than the Justin> source volume, so if one fails, you don’t have to do anything Justin> right away; you’d just need to resolve the issue at some Justin> point, but no interruption to service.
Chris> That's a decent reason to use them.
Justin> LS mirrors can also have a schedule to run to avoid needing to Justin> update them regularly. And, if you need to write to the SVM Justin> root for some reason, you’d need to access the .admin path in Justin> the vsroot; LS mirrors are readonly (like DP mirrors).
Chris> The default for 9.3 seems to be 1 hour, but I bumped it to every 5 Chris> minutes, because I have Netbackup backups which use snapshots and 'vol Chris> clone ...' to mount Oracle volumes for backups. I had to hack my Chris> backuppolicy.sh script to put in a 'sleep 305' to make it work Chris> properly.
Chris> Trying to make it work generically with 'snapmirror update-ls-set Chris> <vserver>:<source>' wasn't working for some reason, so the quick hack Chris> of a sleep got me working.
Chris> But I am thinking of dropping the LS mirrors and just going with DP Chris> mirrors of all my rootvols instead, just because of this issue.
Chris> But let's do a survey, how many people on here are using LS mirrors of Chris> your rootvols on your clusters? I certainly wasn't across multiple Chris> clusters.
Chris> Jhn
Chris> _______________________________________________ Chris> Toasters mailing list Chris> Toasters@teaparty.net Chris> https://www.teaparty.net/mailman/listinfo/toasters
Chris> _______________________________________________ Chris> Toasters mailing list Chris> Toasters@teaparty.net Chris> https://www.teaparty.net/mailman/listinfo/toasters
Chris> This email is being sent by a subsidiary of Arthur J. Gallagher Holdings (UK) Limited, part of the Chris> Arthur J. Gallagher & Co. global group of companies. For details of the registered office, company Chris> number and, where applicable, regulated status of our subsidiaries, please visit Chris> https://www.ajginternational.com/legal-regulatory-information/.
Chris> We are the data controller of any personal information you provide to us or personal information Chris> that has been provided to us by a third party. We collect and process information about you in Chris> order to arrange insurance policies and to process claims. Your information is also used for Chris> business purposes such as fraud prevention and detection and financial management. This may Chris> involve sharing your information with third parties such as insurers, reinsurers, other brokers, Chris> claims handlers, loss adjusters, credit reference agencies, service providers, professional Chris> advisors, our regulators, police and government agencies or fraud prevention agencies.
Chris> We may record telephone calls to help us monitor and improve the service we provide. For further Chris> information on how your information is used and your rights in relation to your information please Chris> see our privacy notice at https://www.ajginternational.com/Privacy-Policy/. If you are providing Chris> personal data of another individual to us, you must tell them you are providing their information Chris> to us and show them a copy of this notice.
Chris> Where you are obtaining a non-consumer policy of (re)insurance, or cover for additional risks or Chris> renewal under an existing policy, you are required to make a fair presentation of the risk to a Chris> (re)insurer which discloses every material circumstance which you know or ought to know relating Chris> to the risk to be insured. A circumstance is material if it would influence the judgment of a Chris> prudent insurer in determining whether to provide insurance for the risk and, if so, on what Chris> terms. Disclosure must be reasonably clear and accessible to a prudent insurer and made in good Chris> faith. The aforementioned duty of disclosure is the applicable duty under the laws of England and Chris> Wales. If your policy is not subject to English law you are expected to disclose risk information Chris> in accordance with the requirements of the applicable law. In such circumstances we expect you Chris> will disclose risk information at least equal to the standard required under English law and where Chris> the applicable law requires you to disclose information over and above the level required under Chris> English law you will provide such information in accordance with that law.
Chris> Where you are obtaining a consumer policy of insurance, you must read each question and answer Chris> honestly and fully and must take reasonable care to not make a misrepresentation.
Chris> Failure to comply with the above disclosure requirements, as they apply to you, could mean that Chris> your policy of (re)insurance is void, its terms are materially altered or that (re)insurers are Chris> not liable to pay all or part of your claim(s). If you are in any doubt as to your obligations you Chris> should ask your usual contact.
Chris> This e-mail and any attachments are CONFIDENTIAL and may contain legally privileged information. Chris> If you are not the intended recipient of this e-mail message, please telephone or e-mail us Chris> immediately, delete this message from your system and do not read, copy, distribute, disclose or Chris> otherwise use this e-mail message and any attachments. Although the above company has taken Chris> reasonable precautions to ensure this e-mail and any attachments are free of any virus or other Chris> defect that may affect your computer, it is the responsibility of the recipient to ensure that it Chris> is virus free and the above company does not accept any responsibility for any loss or damage Chris> arising in any way from its use.
_______________________________________________ Toasters mailing list Toasters@teaparty.net https://www.teaparty.net/mailman/listinfo/toasters
-
André M. Clark -
Chris Hague -
John Stoffel -
Joseph Zoda -
Tim McCarthy