IBM Verify

I will just comment on a couple of items. First, you include use of the ISVD Proxy in your diagram. For most ISVD LDAP server deployments that are (non-container) traditional software installs, the LDAP proxy is not used, and usually is not needed. If you do not have a clear and specific need to use the LDAP proxy component, I would suggest leaving it out. If you are including the LDAP proxy component in your proposed deployment because the company is upgrading from a previous version of the IBM ISVD LDAP server (i.e. SDS 6.4.x) and they already use the LDAP proxy in that existing deployment of their older version, then it would make since to also use it in the new deployment of ISVD 10. But otherwise I would leave out the LDAP proxy component. Most customers put some type of commercial Load Balancer in front of their LDAP servers, and their choice of which load balancer to use is often based on whatever their company is already using for other purposes. Also your diagram seems to show putting the LDAP proxy component in the "App Zone". I am going to guess that there will be some other application-related or authentication-tool related component sitting in some outer network zone such as a DMZ. This component will not be part of ISVD. Whatever it is, it will be the component that will notice when a user is trying to come in and access a resource/application, and that component will check if the user has already authenticated, and if not, that component will be what will call the ISVD LDAP server to verify that a user is who they say they are - for example by verifying that the combination of userid+password is correct. You will want to understand in which network zone that application/authentication component will live (in the DMZ?) and make sure that network connectivity will allow that application/authentication component to talk to whatever load balancer is sitting in front of the ISVD LDAP server instances. 

Second, you show SVDI being installed and running only in Site1. If Site2 exists to allow continued operations if there is a total site failure at Site1, will you need to also have an SVDI instance running at Site2? To answer this question, you might need to understand exactly what the SVDI system will be doing. If SVDI is part of the technology components that get used when users update their passwords, either for normal updates or for self-service password resets, that would be a pretty critical "need it now" operational requirement to have SVDI be able to run at Site2. Also, keep in mind that SVDI does not really "do its own thinking" - instead SVDI does what other things tell it to do. For example, if SVDI is being used to add, delete, and update LDAP accounts for workforce users, based on updates from the company's HR system, then SVDI is basically following instructions from the HR system: the HR system is acting like "the brain", and SVDI is acting like "the hands". So if it becomes necessary to start using an SVDI instance running Site2, how would the company get its HR system to start making its "instructions" get received by the SVDI instance running at Site2? And this same question would need to apply to any other "thing" that acts like "the brain" and sends instructions to SVDI on what it should do.

I will add a comment on having WAS/Web Admin Tool and Directory integrator on the same VM as LDAP/DB2. I would separate those out. I would add another VM just for WAS/Web Admint Tool (WAT) and Directory Integrator. There are many reasons for this, not just resource consumption but patching and upgrades. As Carl stated I would add each of these to the other site. You can keep Directory integrator ALs down, just make sure they do not automatically start up on patching/reboot. I have seen this happen personally and its not good.
As far as proxy servers vs lb its up to you, most do use an lb, F5 is what I see the most of, but in favor of cost you are more than able to use the proxy.