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

From: Rajesh Aialavajjala <r.aialavajjala_at_gmail.com>
Date: Fri, 8 Mar 2019 21:23:19 -0500
Message-ID: <CAGvtKv7T_4aSVS2bFfyTu-+sCoGHg3ZygLbrBNA70X1-Y7dPCg_at_mail.gmail.com>



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

--
http://www.freelists.org/webpage/oracle-l
Received on Sat Mar 09 2019 - 03:23:19 CET

Original text of this message