The biggest issue is to make sure that one sensor (IDSM-2) is receiving both the client and server packets.
The second issue is to try and reduce any duplicate packets being copied to the sensor (sometimes you can't, and have to just deal with it).
In your scenario the server traffic is being marked for capture by the mls ip ids command on the server vlans, but the actual server packets could technically be captured on both the server and client vlans. This is because of an interaction with routing.
The first packet in a connection is often captured on the same vlan where the mls ip ids or VACL was applied. But additional packets are usually captured on the vlan where they exit the switch. This is because mls (also known as fast switching) happens in hardware for additional packets. It will combine the VACLs from both vlans, Router ACLs from the MSFC, and the mls ip ids command into a single hardware implemented ACL on the PFC. The packet comes into the switch and goes to the PFC. The PFC marks it for capture and sends it to the other vlan (vlan being routed to) at the same time. So the packet is a capture packet for the vlan where it is leaving the switch.
The opposite will hold true for the client packets. The intial packets (like the SYN) will be captured on the client vlan, but additional packets will be captured on the server vlan.
The mls ip ids command sometimes even throws a monkey wrench in. Because some of the ip inspect rules are implemented in software and not hardware (not PFC). In which case those packets could still wind up captured on the original vlan instead of the vlan leaving the switch.
The end result is that one sensor has to see captured traffic on both the server and client vlans.
(In your case the 2 server vlans, and all the client vlans).
Some users will want to split up the vlans, and have one sensor monitor a few, and a second sensor monitor others. The problem with this is that the client vlans could have clients talking to both server vlans. So a sensor trying to monitor one server vlan has to monitor ALL of the client vlans. It will see the packets for the servers it is monitoring, but it will also see half the packets for the servers in the other vlan. These half of the packets can wind up having a severe performance hit on the sensor if it doesn't see the other half of the packets. The sensor tries tracking the state of the TCP Sessions, and winds up with these half open TCP Sessions that consume CPU and memory to monitor.
The same will be true for a sensor that tries to monitor just the other server vlan and has to, therefore, monitor all the client vlans.
So the best scenario is to monitor all of the vlans with a single sensor.
Some users will want to have redundancy and have 2 sensors monitor the same traffic. This works fine. Have both sensors monitor all of the vlans.
If a sensor has more than one sniffing interface, some users like to split monitoring over the interfaces.
For example with the IDSM-2 in your case, you could setup port 7 to monitor the server vlans, and setup port 8 to monitor the client vlans. The single sensor (IDSM-2) would be receiving both sides of the connections (one side on each port), and that would work just fine.
What you want to AVOID, however, is having port 7 and port 8 getting duplicate traffic. TO do this you want to ensure that you remove ALL vlans except the server vlans on port 7, and remove ALL vlans except the client vlans on port 8. This way you won't have port 7 and 8 capturing packets from the same vlan.
I generally recommend using just port 7 and disabling port 8 in the sensor's configuration. It makes it easier to configure since only one port has to be setup. And port 7 can handle a GBPS which is more than enough for the IDSM-2 which has a monitoring performance limit of 650 MBPS.
