As the most of you probably know, with AOS 5.6, has been introduced the Volume Group with Load Balancing function, well known as VGLB
As i know the 5.6 version is in short term support.
Now i'm deploying a two Oracle 12c RAC clusters on 2 8000 6-nodes AOS-AHV clusters with AOS 5.5.3.1.
It involves using volume group with multiple vdisk, network related configuration, Linux related tuning and so on...
Of course, with 5.5.3.1 (so far the latest GA version in long term support), i've not the VGLS choice, every volume group's I/O is managed by a single CVM.
By the other side, with AOS 5.6, i could distribute this load on every single CVM and every single node storage on the cluster.
Of couse this heavily impact on the resiliency, the performance and the resources distribution.
The questions are two and i need some suggestions.
1) could be better to upgrade to 5.6 even if it is in short term support?
2) is it possible to update "on the fly" the volumes's configuration with "vg.update load_balance_vm_attacchments" or i should recreate che volumes? (is there a third shot or other related procedures?)
Thank you all so much
UP
Page 1 / 1
Stumbled upon this today, sorry that you didn't get a response from anyone @UPX
1) If you're specifically wanting VGLB's performance capabilities (which are top notch, I was part of the team that worked on validating that features top end performance), then yes, 5.6++ is a good fit.
If you're worried about supportability, note that all STS releases should get at least two patches (example, 5.6, 5.6.1, 5.6.2) before that branch is moved out to another STS release, like 5.8, 5.8.1, etc. These come roughly every ~4-5 weeks, so the
If you're worried about catching bugs, which hey, we're a software company, every software company has bugs, especially in STS/"Current Release" type train models ala us, Microsoft, Citrix, and now VMW ... you could settle on maintenance releases within a STS, like 5.6.1, 5.6.2, then wait to go to other STS releases like 5.8.1, or 5.8.2 (which at time of writing is roughly right around the corner). That should keep you pretty safe.
2) If you haven't figured it out already, you CAN update the load_balance_vm_attachments after creation, however, you have to do it with the VM's off or VG detached from the VM(s). We did this, as to get the targets to log back in again, detach/reattach or reboot anyhow
I haven't personally tried that with RAC, it would be worth playing around with on a test instance to make sure you fully understand the implications there.
1) If you're specifically wanting VGLB's performance capabilities (which are top notch, I was part of the team that worked on validating that features top end performance), then yes, 5.6++ is a good fit.
If you're worried about supportability, note that all STS releases should get at least two patches (example, 5.6, 5.6.1, 5.6.2) before that branch is moved out to another STS release, like 5.8, 5.8.1, etc. These come roughly every ~4-5 weeks, so the
If you're worried about catching bugs, which hey, we're a software company, every software company has bugs, especially in STS/"Current Release" type train models ala us, Microsoft, Citrix, and now VMW ... you could settle on maintenance releases within a STS, like 5.6.1, 5.6.2, then wait to go to other STS releases like 5.8.1, or 5.8.2 (which at time of writing is roughly right around the corner). That should keep you pretty safe.
2) If you haven't figured it out already, you CAN update the load_balance_vm_attachments after creation, however, you have to do it with the VM's off or VG detached from the VM(s). We did this, as to get the targets to log back in again, detach/reattach or reboot anyhow
I haven't personally tried that with RAC, it would be worth playing around with on a test instance to make sure you fully understand the implications there.
Thank you Jon
so i'll update asap and try it on a test environment mirrored from the production.
This Oracle Rac deployment is on two different sites both with 2 istances so this should be not impact the availability
I'll let you know 😉
so i'll update asap and try it on a test environment mirrored from the production.
This Oracle Rac deployment is on two different sites both with 2 istances so this should be not impact the availability
I'll let you know 😉
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.