We have added multisubnetfailover=true to our App Fabric connection strings and get a "keyword not supported error" in App Fabric. I cannot find any articles describing this and wanted to know if anyone has dealt with this issue (and hopefully resolved it)?
Depending on which version of .Net you're using, you might have to install this update - also make sure your connection string is pointing to the Availabilty Group Listener:
If you upgrade a SqlClient application that currently uses database
mirroring to a multi-subnet scenario, you should remove the Failover
Partner connection property and replace it with MultiSubnetFailover
set to True and replace the server name in the connection string with
an availability group listener.
Related
We are currently transitioning our apps to Kubernetes and I have two apps, appP and appH, that I need to communicate with each other over a port unknown at start up time.
Unlike most of our apps, we don't have a set port for them will to communicate over. Before Kubernetes, third party app (out of my control) would tell appP to start processing an item, itemA, identified with a unique id and it would also tell appH to handle the processed data produced by appP.
To coordinate communications between appP and appH, appH would generate a port based on the unique id and publish the host and port info to connect on to an intermediate app (IA). appP, once done with it's processing queries IA for the connection information based on the unique id and sends it over.
Now we have to adapt this to kubernetes. Each app runs in its own deployment, as does the IA. So how can I setup appH to accept the connection over a port without being able to specify it in the service definition?
Note: I've seen some posts say that pods should be able to communicate to any other pods in the cluster regardless of specifying the ports in the service definition but I can't seem to find a ton of confirming information on this and I don't have a ton of time on our cluster where it is free to bang my head against.
Would it would just fine as is regardless? My biggest worry is the ip resolution. Currently appH grabs its ip based on the host it's running on (using boost). Not sure how this resolves within a container.
If not, my next thought would be if I could setup a headless service with selector for appH in order to allow for ip resolution. What I am unsure of then is if I could have appP connect to <appH_Service>:<arbitrary_port>?
Would the service even have to be headless in this scenario? I mostly say headless w/ selector because I saw in one specific post that it is the only one you don't need a port in the spec for it. Also because I am unsure if the connection would go through unless it was the actual pod's ip it was connecting with, rather than the services.
Any info or clarification is appreciated. For the most part, I can't really change the architecture of these apps right now, I just have to get them talking to each other as is and haven't found a ton of clear information on this type of case.
Note: We use helm and coredns if anyone is curious.
The Kubernetes networking model is as follows: a Pod is a group of containers that share a single network identity (a cluster IP). Any port exposed by a container is thus automatically exposed on the Pod. The model demands that each Pods can communicate with other Pods.
This means that your current design can work without modifications.
What Services bring to the table is that you can bring a stable network identity to a group of Pods that is otherwise very volatile. It does not apply to your appP/appH coupling, I think.
the error i m gettingenter image description hereMy intention is to have ORACLE 12 + Informatica on my local system.
I have installed Oracle and it is working fine. While I am trying to run SERVER INSTALLATION for INFORMATICA, I am having difficulty with configuring the database for domain connection repository. The connection is failing even though I am giving correct oracle credentials which are as below:
DB USERID: infadmin
JDBC URL:localhost:1521
Service: orcl
My questions is:
Why is it failing? Do I have to do anything special before trying this connection like installing any special jdbc drivers or something?
Your replies are much awaited.Thanks in advance.
Vaibhav Gautam
Check the contents of the tnsnames.ora file located at <Oracle Installation Direcotry>/network/admin. Make sure that the hostname, port no., service name matches exactly.
Also, make sure the oracle service is running.
I am migrating my vCenter Server 5.5 to a new server (databases have already been moved to a new SQL server and all is OK on existing vCenter Server 5.5 implementation). When I begin the simple install process on the new vCenter Server host the Single Sign-On component presents me with an IP address of 10.10.10.117 as the ip address of the FQDN file01.xxxxxxxxx.com. This is the iSCSI interface address. I need it to use the 10.1.1.17 ip address that is the address of the production NIC that the ESXi 5.5 hosts will be communicating with. I have already changed the binding order of the NIC cards and flushed the DNS cache. I also added file01.xxxxxxxx.com with the proper IP address to the hosts file and also file01 to the hosts file. Still, during the install, 10.10.10.117 is discovered. Thanks in advance! Babak C.
Just to get a quick clarification...are you freshly installing vCenter 5.5? Or are you migrating an existing vCenter server to a new host and using the update utility to upgrade? I am assuming you are doing a fresh install based on your details about the SQL server and SSO. Here is my suggestion, in case it is a fresh install.
We had a similar problem with 5.5 on a new install where the IP address that was discovered during the actual vCenter Server install was that of the public facing NIC which we never use for management traffic (it's for internet access on the vC server, for update manager, etc.)
The strange thing is that there had NEVER been an entry in ANY of our DNS servers for that interface. So, after looking into it a little bit, I started thinking the IP that was returned during install was not a DNS result at all. Rather, it was (most likely) simply gathered from the interfaces on the Server based on binding order (e.g. which NIC has the default gateway.)
In order to save having to uninstall and clean up a major mess if the install completed wrong, we stopped and got in touch with VMware support. They suggested we clear all of the temporary files both in the standard "temporary" folder on windows as well as under /ApplicationData/vmware/xxx, where 'xxx' would be whatever product is giving you trouble and HAS NOT been FULLY INSTALLED* (e.g. you started the install and noticed the incorrect IP, so you terminated the installer and there is metadata and cached files remaining from the partially run install).
Basically, what we had to do, was clear the temporary files and then make sure the NIC Binding Priority was correct (so you should check in Network Adapters|(press-alt)|Advanced Settings. Make sure the correct binding is checked (e.g. if you don't use IPv6 on the private network, clear it) and make sure that the Windows Network is at the top of the priority list on the second pane of the advanced settings. This helps tremendously with SSO by making sure the Windows Network stack is the first queried when you are signing in and SSO must submit a kerberos ticket to the AD DC for validation.
It is possible, that once you delete the partial install files and temporary files and fix the network settings (probably be a good idea to reboot as well), the next time you run the installer you might have success.
I will try to check this post later to see if it helped you at all... or it I just succeeded in making your life even more difficult (which I certainly hope not!) :)
One more thing...prior to initializing the installer, open up a PS session, perform ipconfig /flushdns and then ping the hostname of your vCenter server in order to get it in the DNS cache. You should also perform the following:
nslookup
NS>{your vcenter server IP address}
/* make sure the resulting hostname is correct..this ensures your PTRs and rDNS is working correctly. vCenter HEAVILY relies on accurate reverse DNS configuration...then do the following lookup for forward DNS */
NS>{your vcenter server FQDN}
Hope it helps. Best of luck my friend!
SIETEC
I am creating a custom service in on a single node instance of CloudFoundry which I build from vcap_dev_setup. I have followed these instructions to get an idea of what todo when creating new services.
When I try to start the new service gateway by running 'vcap_dev start service_gaeway' I get the following error:
Exiting due to NATS error: Could not connect to server on nats://nats:nats#172.16.4.146:4222/
The configuration for the :mbus property on the service_gateway is fine and is identical to that of all of the other services which start without issue.
Does anyone know of any reason why a single service could not connect to nats correctly assuming the configuration is correct?
Thanks
Chris
I am not sure why this would be the case, assuming other services are able to connect to NATS
If you are willing to share your changes to VCAP as a patch I will happily take a look, what service are your looking to integrate?
I would also advise posting your query to the VCAP dev google group at https://groups.google.com/a/cloudfoundry.org/forum/?fromgroups#!forum/vcap-dev
Make sure you have NATS running on the IP address: 172.16.4.146 Port: 4222
The IP Address should most likely be your localhost. DHCP most likely has assigned another IP addresst other than 172.16.4.146. Make sure your computer has 172.16.4.146 as IP address. You can check that by doing ifconfig.
The tricky problem may be caused by a version conflict with misleading exception, you could have a try with the latest code;
After installing VMware Server I get the following error when I try to access the VMware web-based server manager:
The VMware Infrastructure Web Service
at "http://localhost:8222/sdk" is not
responding
Go into the services manager and check that the 'VMware Host Agent' service is running. If not, then start it and then try browsing to the site again.
Vmware Hostd was not working for me either.
However, in trying to start the service it stopped automatically. Typically when this happens it is because there is an error in your config.xml.
C:\ProgramData\VMware\VMware Server\hostd\config.xml
In my case, checking the logs at:
C:\ProgramData\VMware\VMware Server
showed it erroring out after "Trying hostsvc".
Searching the config.xml for hostsvc showed references to several things, the first thing was the datastore. In checking my datastores.xml file:
C:\ProgramData\VMware\VMware Server\hostd\datastores.xml .
I found it full of all sorts of random characters instead of a properly formed XML document.
Renaming datastores.xml to datastorex.xml.bad allowed me to start the service. At which point I had to add back my datastores through the GUI.
Hopefully this will help someone else out. I did not find any other references in Google to this issue.
Try accessing via "http://localhost:8222" without the /sdk. You can also try the secure site via "https://localhost:8333".