As per this BOL reference, here are the only options you would have with Standard edition:
- Log Shipping
- Database Mirroring (sync/safety only)
- 2-node Failover Cluster Instance
Because you don't want to use shared storage between different participants, that would automatically rule out the failover cluster instance, leaving you to choose between log shipping and database mirroring.
Those are two very different solutions, with two very different needs driving them. What are your requirements for failover? Reporting? How many copies of the data do you want? Until those questions are answered, you wouldn't be able to choose between these two rock-solid solutions.
EDIT
I must have completely missed your requirements in your question, but with Paul's excellent edit and graphic there, it seems as though a lot of the requirements are already there (although you don't seem to point out reporting or warm data, so I'll assume that's not necessary).
Physical Separation
You could get yourself into trouble here with database mirroring if you're talking about cross-datacenter or geographic separation type of distance, as the restriction for only sync/safety mode could introduce performance implications.
Failover Tolerant Application
Unless you have the logic in your application, log shipping wouldn't be able to help you here. With database mirroring, depending on your provider and capabilities you could specify the failover partner though.
Failover (preferably automatic)
This an easy one. Log shipping doesn't have this capability, you'd have to manually intervene. Database mirroring would be able to fulfill this.
No Shared Storage
Both of these solutions do not require shared storage.
Must work with EF
I don't see why EF would have a problem with database mirroring, but I couldn't say for sure on this without doing more EF research.
SQL Server 2014 Standard
If you mean Standard edition, that is answered above. If you mean "standard" as in "current", then database mirroring is currently deprecated for what it's worth.
Creating a listener creates (permissions must allow, otherwise the entry will be made by the network team) a DNS entry, and has a dependency to an IP address. It logically follows that each listener needs its own IP address, because how else will traffic know where to be directed?
See Failover Cluster Manager>[Cluster Name]>Services and applications> [Availability Group name]. Under Server Name section, the listener name is displayed and shows the IP Address underneath, which is reflected as a Dependencies entry if you open the properties of the listener name.
If you find a way around it, I'd sure like to know, because it doesn't make sense to me that it would work. Good luck!
Best Answer
With SQL Server 2014 Standard Edition you can create a two-node failover infrastructure. For that, you need to have in each node at least Windows Server 2008 R2 SP1 Standard, because you need to first generate a failover cluster with Windows Server.
If you want a multi-instance failover cluster, then you need to generate two SQL Server 2014 installations, since the product works in an Active-Passive mode. I mean, you will need to install the first instance, SQL1 and then you will proceed with the second instance, SQL2. You will need to configure each instance so SQL1 runs in node 1 and SQL2 runs in node 2.
Also, it's very important and recommended, that you have at least a SAN or some device that can provide you with the shared storage schema, since previous to the SQL Server failover cluster installation you need to validate the Windows Server failover cluster support to the SQL Server one.