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

My thanks for replying...multiple times...

When you mention that the Exadata m/c was not made for physical separation - relative to the Interconnect - are you alluding to the InfiniBand fabric?

Thanks,

--Rajesh

On Sat, Mar 9, 2019 at 12:44 AM <dimensional.dba_at_comcast.net> wrote:

> I wish you luck, as the Exadata was not made for physical separateness,
> relative to the Interconnect..
>
>
>
>
>
> *From:* oracle-l-bounce_at_freelists.org <oracle-l-bounce_at_freelists.org> *On
> Behalf Of *Rajesh Aialavajjala
> *Sent:* Friday, March 8, 2019 7:19 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 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