Port number change
- Sequential port numbers for each instance. Just pick some.
- Port numbers that match instance name (eg xxx1 = InstanceA, xxx2 = InstanceB)
- No app this century should require "default" port 1433. They should resolve instance name. Only the default instance (which won't apply here) should use 1433.
- If you change the port, some clients may cache the value but it should just work. If this is a new cluster then you shouldn't need to change anything.
I remember when working with clusters that the port change from dynamic to a static one doesn't take effect if you don't disable the checkpointing of the quorum.
Here are more details: How to Change the Dynamic Port of the SQL Server Named Instance to an Static Port in a SQL Server 2005 Cluster
Also, applications managers should be notified about the port change because there are places where this can be used. As well, the port of SQL Server Instance is used in Firewall settings in many types of network configurations.
The port number you select doesn't matter. Static port numbers should only be needed if you need to specify holes through a firewall which isn't on the local server. All SQL Server client drivers can convert the instance name to the TCP port number automatically using the SQL Server Browser.
The nice thing about using dynamic port numbers is that the TCP port will always be available. If you specify a static port number, there is a risk that something else will grab that port before SQL Starts up (I've seen this happen before) which will cause SQL to start without grabbing the port.