keithdew_at_comcast.net wrote:
> Unfortunatley - I'm a networking person trying to assist our UNIX/DBA
> team. But, yes, I agree with your understanding of Network Bonding.
> It bonds 2 or more NIC's together to aggregate bandwidth which should
> have nothing to do with VIP's on multiple subnets.
>
> The bottom line is, we have a 3 node cluster. Each node has a public,
> private and (what we call) an isolated batch subnet NIC (3 NIC's total
> per node). Our Application vendor indicates that it is "strongly"
> encouraged to have this isolated network (where bulk batch processing
> takes place) and not compete with the public NIC where the clients
> access the application. In total, this is 3 seperate IP subnets per
> node. Our Unix/DBA's need to have multiple VIP's to service
> the applications that need to use the public and isolated batch
> subnet. One VIP to listen on the the client side for the actual
> application. And another VIP that will listen on a totally different
> subnet (the isolated batch network) that of course has it's own NIC.
> So, our concern is from what we have heard so far is that it appears
> the VIP per node that any application can use is only available on the
> "public" facing NIC
>
> Thanks
> Keith
I think your vendor may have some misconceptions with respect to how RAC
works. What I would recommend is creating two services. One for your end
users that connects them to two nodes and a second service for the batch
process that connects to the third. I can't see where a batch process
requires a separate physical network and, if it does, they should be
thinking NIC bonding for more through-put as latency should not be an
issue.
--
Daniel A. Morgan
University of Washington
damorgan_at_x.washington.edu (replace x with u to respond)
Puget Sound Oracle Users Group
www.psoug.org
Received on Tue Aug 07 2007 - 10:48:48 CDT
