Re: RAC 12.2 - Exadata X6-2 - Network Isolation between Databases - W/O VLAN tags

The merits of rebuilding to a VM based solution are germane-unfortunately it might not be a viable option - if these requirements had been stated prior to the build - I fully agree that a more suitable solution might have been architected...

Under the current circumstances-the effort is to try and avoid a rebuild-given that the current infrastructure hosts a production environment...

The requirement might rightly demand or suggest the same but my effort is to try and see if there exists another option...

Thanks,

—Rajesh

On Fri, Mar 8, 2019 at 21:47 <dimensional.dba_at_comcast.net> wrote:

> …and with a rebuild you could get the system rebuilt as 19c for the GRID
> infrastructure and Storage Cells and then not have to go through that later.
>
>
>
> *From:* dimensional.dba_at_comcast.net <dimensional.dba_at_comcast.net>
> *Sent:* Friday, March 8, 2019 6:41 PM
> *To:* 'Rajesh Aialavajjala' <r.aialavajjala_at_gmail.com>
> *Cc:* 'ORACLE-L' <oracle-l_at_freelists.org>
> *Subject:* RE: RAC 12.2 - Exadata X6-2 - Network Isolation between
> Databases - W/O VLAN tags
>
>
>
> I understand the potential pain to get there.
>
> From a logical perspective there is a way to navigate there, but it really
> depends on how your ASM disks were already divided up as each VM RAC
> Cluster gets its own disks.
>
> The ASM part is the tricky part, really requiring the rebuild from scratch
> so that it is built right and supported.
>
> If you have Oracle Platform Support, I would have a discussion with them
> first. Rebuild to a new configuration and Upgrade/Patching sometimes can
> all be considered the same thing.
>
>
>
>
>
>
>
> *From:* Rajesh Aialavajjala <r.aialavajjala_at_gmail.com>
> *Sent:* Friday, March 8, 2019 6:34 PM
> *To:* dimensional.dba_at_comcast.net
> *Cc:* ORACLE-L <oracle-l_at_freelists.org>
> *Subject:* Re: RAC 12.2 - Exadata X6-2 - Network Isolation between
> Databases - W/O VLAN tags
>
>
>
> The challenge now is taking down the environment and converting to
> VM...hoping to avoid that option
>
>
>
> A tear down and rebuild is a sub optimal option...
>
>
>
> Thanks,
>
>
>
> —Rajesh
>
>
>
> On Fri, Mar 8, 2019 at 21:25 <dimensional.dba_at_comcast.net> wrote:
>
> Even under government requirements they allow the VM separation.
>
> Normally only if you are handling Top Secret Data/Top Secret
> Compartmentalized Data is there an absolute physical separation required.
>
>
>
>
>
> *From:* Rajesh Aialavajjala <r.aialavajjala_at_gmail.com>
> *Sent:* Friday, March 8, 2019 6:23 PM
> *To:* dimensional.dba_at_comcast.net
> *Cc:* ORACLE-L <oracle-l_at_freelists.org>
> *Subject:* Re: RAC 12.2 - Exadata X6-2 - Network Isolation between
> Databases - W/O VLAN tags
>
>
>
> Thanks for replying...
>
>
>
> Unfortunately-switching to VM isn’t really an option...I did think of that
> but it won’t happen...
>
>
>
> This is a commercial enterprise but they have government customers who
> have government requirements...
>
>
>
> Thanks,
>
>
>
> —Rajesh
>
>
>
> On Fri, Mar 8, 2019 at 21:06 <dimensional.dba_at_comcast.net> wrote:
>
> You could switch to VM’s on the Exadata to solve the problem.
>
> It all depends on your specific organizations guidelines.
>
> With the VMs then the Infiniband can be subnetted at the Dom0.
>
>
>
> This seems a fairly odd requirement
>
> “now I'm being told that the new databases have to be cabled to a switch
> different that the ones that are currently connected to this machine on
> bondeth0 (Client N/W)”
>
> Considering all the cloud infrastructures internal/external and simple VM
> setups.
>
>
>
> The fact that they say this
>
> “*This subnet cannot be accessible from other subnets and will be
> firewalled per NIST guidelines*. “
>
>
>
> Implies they are already using firewalls to divide traffic instead of
> having everything on different physical separate network equipment.
>
>
>
> Side note, what business sector are these requirements in? I assume
> government of some sort.
>
>
>
>
>
>
>
> *From:* oracle-l-bounce_at_freelists.org <oracle-l-bounce_at_freelists.org> *On
> Behalf Of *Rajesh Aialavajjala
> *Sent:* Friday, March 8, 2019 5:10 PM
> *To:* ORACLE-L (oracle-l_at_freelists.org) <oracle-l_at_freelists.org>
> *Subject:* RAC 12.2 - Exadata X6-2 - Network Isolation between Databases
> - W/O VLAN tags
>
>
>
> I've come across a rather interesting requirement (like most that get
> posted about here in oracle-l)…
>
>
>
> I'm running on an X6-2 Exadata bare metal 1/4th rack that has the
> following requirement – “What is needed at a high level is to segment a few
> or our databases onto a *new subnet. This subnet cannot be accessible
> from other subnets and will be firewalled per NIST guidelines*.
>
>
>
> My first thought was that I could setup a VLAN tagged interface on the
> bondeth0 (client n/w) <Enabling 802.1Q VLAN Tagging in Exadata Database
> Machine over client networks (Doc ID 1423676.1)> to facilitate the
> isolation that is being requested – this is an running machine installation
> and the ask is to add databases that meet this ‘isolated’ requirement…
>
>
>
> However – now I'm being told that the new databases have to be cabled to a
> switch different that the ones that are currently connected to this machine
> on bondeth0 (Client N/W) - and this eliminates VLAN tagging since the
> interfaces will not be 'shared' but physically separated...
>
>
>
> The use of either the 'quad card' or an add on PCI card will give me the
> extra physical interfaces to create say 'bondeth1' - that's probably easy...
>
>
>
>
> https://docs.oracle.com/cd/E62159_01/html/E62171/z40013721408059.html#scrolltoc
>
>
>
> HA / RAC is a requirement and I have only 2 compute nodes - so if I want
> to add a 2nd network can it be in a different subnet? I know w/ 12c RAC
> (this is 12.2 GI) I can have a 2nd SCAN listener in a separate / different
> subnet but where this defeats me is the "*This subnet cannot be
> accessible from other subnets"* - I cannot envision how the Grid
> Infrastructure can do this - if the subnet is isolated - the GI cannot get
> to it and thereby cannot manage it...most of the use cases that I have
> found discuss setting up a 2nd n/w in RAC for either DG or backups - not
> like this...
>
>
>
> I guess one option is to try and run on just 1 node each and having to
> re-ip the 2 compute nodes but that takes away the RAC/HA part …
>
>
>
> I'd greatly appreciate any suggestions/advice...
>
>
>
> Thanks,
>
>
>
> --Rajesh
>
>
>
>
>
>
>
>
>
>
>
> --
>
> Sent from Gmail Mobile
>
> --
>
> Sent from Gmail Mobile
>

-- 
Sent from Gmail Mobile

--
http://www.freelists.org/webpage/oracle-l