Access Couchbase on Azure Windows 2012 VM from .net

.NET SDK
1

I’m trying to get a new instance of Couchbase set up on Azure, and having trouble connecting from the .net SDK.

For setup, I have followed steps here: http://blog.couchbase.com/step-step-production-deployment-couchbase-windows-azure-virtual-machines (took several attempts to get this up and running on an azure virtual network)

Have installed Version: 2.5.1 enterprise edition (build-1083) on windows Server 2012 R2.

I’m running only one VM to begin with. Medium sized, serving nothing but couchbase.

Have opened azure ports both on the machine itself, and the azure cloud service. Have set new inbound rules on the VM firewall according this document: http://docs.couchbase.com/couchbase-manual-2.0/#network-ports. On the Azure cloud service, I’ve opened anything marked as ‘node to client’ from that document (8091, 8092, 11210, 11211).

Everything seems to be fine in the browser. From my dev machine, I can load couchbase from the azure VM external IP. I have logged in and added a testdoc to the ‘default’ bucket. I can view this document in the browser, and everthing appear good.

The problem is when I start trying to access from .net application. When I try to .ExecuteGet the testdoc, I’m getting ‘Unable to locate node’ message, and the resulting doc is null.

Logs are telling me that the address is ok, but there is an error at System.Dns.GetAddrInfo(String name). Here is the full log up to the error:

2014-09-12 14:40:58,291 [10] DEBUG Couchbase.CouchbasePool [(null)] <(null)> - Initializing Couchbase.CouchbasePool

2014-09-12 14:40:58,345 [10] WARN Enyim.Caching.MemcachedClient [(null)] <(null)> - Creating new client. CID: ffcc1454-1146-4fac-94b6-c74dae07ca4b CouchbaseClient

2014-09-12 14:40:58,348 [10] WARN Couchbase.CouchbasePool [(null)] <(null)> - Starting Couchbase.CouchbasePool

2014-09-12 14:40:58,468 [10] WARN Couchbase.MessageStreamListener [(null)] <(null)> - Starting the listener. Queue=True

2014-09-12 14:40:58,485 [3] WARN Couchbase.MessageStreamListener [(null)] <(null)> - Started working.

2014-09-12 14:40:58,518 [3] WARN Couchbase.MessageStreamListener [(null)] <(null)> - Looking for the first working node.

2014-09-12 14:40:58,621 [3] DEBUG Couchbase.ConfigHelper [(null)] <(null)> - Found config for bucket default.

2014-09-12 14:40:58,622 [3] WARN Couchbase.MessageStreamListener [(null)] <(null)> - Resolved pool url http://xx.xxx.xx.xxx:8091/pools to http://xx.xxx.xx.xxx:8091/pools/default/bucketsStreaming/default?bucket_uuid=d679672b019cff2053f507a2f4fd642a

2014-09-12 14:40:58,622 [3] WARN Couchbase.MessageStreamListener [(null)] <(null)> - Start receiving messages.

2014-09-12 14:40:58,661 [3] INFO Couchbase.CouchbasePool [(null)] <(null)> - Received new configuration.

2014-09-12 14:40:58,717 [cbp_thread] INFO Couchbase.CouchbasePool [(null)] <(null)> - Has vbucket. Server count: 1

2014-09-12 14:40:58,803 [cbp_thread] ERROR Couchbase.CouchbasePool [(null)] <(null)> - Failed to initialize the pool.
System.Net.Sockets.SocketException (0x80004005): The requested name is valid, but no data of the requested type was found
at System.Net.Dns.GetAddrInfo(String name)
at System.Net.Dns.InternalGetHostByName(String hostName, Boolean includeIPv6)
at System.Net.Dns.GetHostAddresses(String hostNameOrAddress)
at Couchbase.CouchbasePool.GetFirstAddress(String hostname)
at Couchbase.CouchbasePool.InitVBucket(ClusterConfig config, ISaslAuthenticationProvider auth)
at Couchbase.CouchbasePool.ReconfigurePool(ClusterConfig config)

2

Hi Brett,
This typically happens because your couchbase cluster node references are built using private IPs and not the public IPs or names. When the client machine tries to resolve the private IP, if they are in separate regions or not in the same private network, it cannot resolve the addresses to the server nodes. Could this be the issue in your case?

by the way apologies for not being clear on this article. Do you have any suggestion how to improve the article to make it easier for others? if you discovered gotcha’s would be good to note those as well.
http://blog.couchbase.com/step-step-production-deployment-couchbase-windows-azure-virtual-machines
-cihan

3

Hi Cihan,
Thanks for the reply. I will try putting my dev vm into the same private network and give it a shot with the internal IP, though it isn’t exactly clear why that should make a difference. I’m able to access the documents from the dev machine in the browser (using the public IP), so it feels more like a .net client error.

WRT gotchas in the article, I struggled a bit with the Azure port settings. It is clear enough about opening the ports on the server machine, but for public IP access to the management interface, you have to open ports on the Azure portal too. Had to make some guesses about which ones to open, and still not sure if I’ve done a good thing or not. Also, maybe a topic for a follow on post (or a few extra words) would be specifically about setting up a development environment against the couchbase instance. Are there any best practices to allow a team of dev’s (not on the cloud) access, but not expose data to the world. I’m specifically looking at couchbase for a new project, but have a lot of infrastructure and process questions still about how to get my .net team transitioned and up to speed.

4

Thanks. welcome the feedback. I’ll move the port setting into the article and be more deliberate about which ones to open. has been a while since I put these out.

Generally, setting up the app servers under the same subnet is a good practice because you want the app servers to have low latency access to couchbase. Otherwise, every time the app server/dev env hits public IP, it has to travel a longer distance. Another benefit from running apps and couchbase nodes under the same subnet is you don’t have to poke holes for data access path to be open on the firewall protecting public IPs.

let me know if you are still seeing the issue with connectivity. thanks
-cihan

5

My plan for production is certainly to have app servers on the same subnet. Getting the dev machines onto that subnet is a bit more of a reach. Don’t really care about the additional latency during development, as long as it works. I’m also not keen on spinning up development VM’s just for a couchbase trial run. Difficult to justify those costs up the chain of command, and it gives the impression of being a bit half baked, really. I’m sure there must be a way to set it up, but infra isn’t really my strong suit :-S. Anyway I’ll post back with results. Thanks for the help!!

6

If you want to expose the cluster to the internet you can. Just set it up so that you have the public IPs as the node names (inctead of using 127.0.0.1 for the node IP, use the public name. This is done during couchbase setup. if the node names you register are either public IPs or public DNS names, any client machine can resolve the server address it is trying to reach.

Esentially when you give your client app the name or the IP to connect to for reaching couchbase server, you are specifying one or more nodes in the cluster. However after the connection the client has to be able to enumerate any cluster node. so we communicate the cluster map and that contains the node address you registered when setting up the couchbase cluster. the address can be a DNS name or a IP but the client at that point has to be able to resolve those destinations.

7

Aha, that makes more sense. I (finally) get it. Anyway, I got a new dev machine set up on the same virtual network, edited the hosts file on the client to help resolve the internal hostname which I used when installing couchbase, changed the app.config to use that same name and, voila. Everything working as expected. Thanks for all the help and answers!