I have talked with some Oracle DBAs, and they told that there is a component called Oracle Listener ( http://docs.oracle.com/cd/B19306_01/server.102/b14196/network.htm ) that permits to filter the network traffic to a database, for example when the machine has many network interfaces.
Is there any tool similar in DB2? or how can I do this? because I just can configure one port per instance, and that is all. If I want to configure more, I have to do it via IPTables of firewall. However, I cannot configure which users, applications, or workload should connect which network interface.
A database server is generally not a good place to implement and manage a complicated networking scheme. From a CPU standpoint, you’d be better off delegating that responsibility to more specialized equipment (switches, routers, firewalls, etc.), and saving precious CPU cycles for database query processing instead. Running a simple, straightforward network configuration on the database server will also make it easier to secure your databases, because fewer administrators will require root access on the database server when it doesn’t require regular attention from network admins.
Although the DB2 instance listens on just one TCP port (specified by the DBA), it will listen on that port on multiple network adapters and multiple IP addresses defined on those adapters. The instance will also listen on other network protocols that you’ve specified via the DB2COMM registry variable. Nothing at the DB2 configuration level controls which local NICs and/or IP addresses are allowed to accept inbound DB2 connection requests. However, when such granularity is needed, it’s best to handle that from a dedicated firewall or router rather than a copy of iptables running locally.
I can’t think of a reason that DB2’s policy of one TCP port number per DB2 instance should be treated as a limitation. Even if DB2 allowed it (or could be tricked into doing so), listening on additional ports wouldn’t accelerate response times for establishing a database connection, nor would it provide the instance with any more bandwidth than it already had. Increasing the number of agents/threads would change the performance characteristics, but none of those actions require the instance to listen on more than one TCP port. It would help if I understood the nature of your current (or anticipated) problem that stems from this policy.
If some of your questions are based on concerns about a NIC being a single point of failure, you may want to look into ethernet bonding, which creates the appearance of a single logical NIC from a pair of physical NICs. This is handled by networking features of the operating system, effectively hiding the complexity from database servers and other networked applications.
Network adapters in most servers now operate at gigabit speeds or faster, which all but eliminates the risk of the NIC being saturated by legitimate database traffic. If your DB2 application workload really is pushing the gigabit per second boundary all by itself, then congratulations, your organization is probably getting enough value out of the database to consider clustering it across multiple physical servers (InfoSphere Warehouse or DB2 pureScale, depending on the workload). If you’re occasionally encountering network contention on the DB2 server that is caused mostly by other traffic, such as network-attached storage or network-based backups, that traffic can be isolated to specific NICs and away from the DB2 clients through network addressing techniques and some routing/switching hardware.