I am trying to create a Cassandra cluster. For inter-node communications, on each node, I am using a separate interface with an internal IP address that is not accessible form outside. In addition each machine has an interface that has an external IP visible from outside.
Cluster works fine when a client can use internal addresses. But when I am trying to connect to a node using an external address, the connection itself works, but cluster is described to a client using internal addresses. As a result, client fails because it cannot connect to Cassandra nodes using reported internal addresses.
Is there a way to make Cassandra cluster to report DNS names (or external IPs) of the nodes instead their internal IP addresses?
In cassandra.yaml set listen_address to the internal IP, and rpc_address to the external IP, just follow the instructions in the comments.
Just got this working, the change was with broadcast_rpc_address, change that to your external IP in the cassandra.yaml file and restart cassandra.
Related
I've recently found out that the external network for our OpenStack (Ocata) setup has maxed out on the available IP addresses in its allocation table. In fact, it has over-allocated with -9 free IPs. So, to manage the limited IP addresses, is it possible to access an instance in a project directly from an external network (internet) via the project's router? This way only a single IP address needs to be allocated per project instead of allocating to multiple instances per project.
The short answer would be NO, but there are couple of workarounds that came to my mind (not that they will be good, but they will work).
In case any instance in your private network has floatingIP, you can use that host as a jump-host (bastion-host) to SSH into the target host. This also brings the benefits of port forwarding/SSH tunneling to the table if you want to access to some other port.
You can always access to any host on private networks through qdhcp or qrouter namespace from the network node
ip netns exec qdhcp-XXXXXXX ssh user#internal-IP
I have a TCP Server for a my personal chat, I want to expand my connection beyond my local network and I want to open my port: 28752 to my IP public of pc to enter wherever I want only when my computer is on.
I have seen different solutions for example DMZ to associate my local IP to public IP, but i want to do this without modifying to router's setting I wanted to do it from a program. Is it possible?
It is possible to open up ports. But it depends on the OS in which you are trying to accomplish it. You can use the linux iptables to manipulate the ports opened and closed to any linux machine. IptablesSome examples . The ports should also be opened on the firewall layer outside the VM. eg: It could be AWS access policy, Security group, MAC's security firewall. Your laptop, when connected to the internet, will have a public IP address, you can share that public IP. But these IP address will change when you get connected to a different router. You can use AWS cli commands to assign a static IP address for your machine and expose it publicly. At the least minimum, you would need a public DNS server to expose your IP publicly. Easy way to achieve this is by putting in web server on cloud. Without a domain , you cant expose your IP. Once you have finalized on the domain (eg: AWS Route 53, Ingree IP from K8 etc), you can change/manipulate them from your program. It need not be language specific.
In a vmware environment, should the external address become populated with the VM's (or hosts) ip address?
I have three clusters, and have found that only those using a "cloud provider" have external addresses when I run kubectl get nodes -o wide. It is my understanding that the "cloud provider" plugin (GCP, AWS, Vmware, etc) is what assigns the public ip address to the node.
KOPS deployed to GCP = external address is the real public IP addresses of the nodes.
Kubeadm deployed to vwmare, using vmware cloud provider = external address is the same as the internal address (a private range).
Kubeadm deployed, NO cloud provider = no external ip.
I ask because I have a tool that scrapes /api/v1/nodes and then interacts with each host that is finds, using the "external ip". This only works with my first two clusters.
My tool runs on the local network of the clusters, should it be targeting the "internal ip" instead? In other words, is the internal ip ALWAYS the IP address of the VM or physical host (when installed on bare metal).
Thank you
Baremetal will not have an "extrenal-IP" for the nodes and the "internal-ip" will be the IP address of the nodes. You are running your command from inside the same network for your local cluster so you should be able to use this internal IP address to access the nodes as required.
When using k8s on baremetal the external IP and loadbalancer functions don't natively exist. If you want to expose an "External IP", quotes because most cases it would still be a 10.X.X.X address, from your baremetal cluster you would need to install something like MetalLB.
https://github.com/google/metallb
I have two environments on jelastic 4.7. On one of them I have a Java Stack and a Redis server that need to be kept private without a public IP address. On the other environment, I have a Node.js Stack that have a Public IP.
So, Im searching the docs exhaustively and can't find the answer to the question.
Can I access the private IP and port of my Redis from the node app?? Every node on Jelastic has a local ip address. Can I access those between environments??
I think it's a simple question. I'm trying to avoid the overhead of creating a public IP Address for Redis.
Can I access the private IP and port of my Redis from the node app??
Every node on Jelastic has a local ip address. Can I access those
between environments??
Yes, you can connect to different nodes of different environments using just a local IP within one hosting provider or its regions (depends on providers setup). Also, you can use Endpoints in order to connect to local IPs of other providers or to the regions within one provider, if direct connection can't be established.
Besides that, you can use, for example, CNAME of database instead of a local IP.
Like if one is on 192.168.1.1 and the other on 192.168.1.2, can you configure the machine's to each other's static IP addresses and thereby have them start receiving information for each other's InstanceInputEndpoints (since now the Azure gateway should route the InstanceInputEndpoint to the new owner of the IP address)?
No, you can't do that!
And, as of today (Dec. 2013) you are highly advised to never set static IP Address of your Virtual Machine inside Windows Azure! You should always use default DHCP configuration. If you wand IP Address predictability check out this blog post. You can still use Azure Virtual Network with Web and Worker Roles and have IP Address predictability.
If you use VM you should create several VM and a Networks, define address space you will use. When you create a VM, make sure your VM is using the networks that you create. If you forget to include the vm into the network, you need to recreate the VM.
Example how to change the internal IP using 3 VM:
Server A is connected to the network and get ip 192.168.0.1
Server B 192.168.0.2
Server C 192.168.0.3
shutdown all your server from azure portal so that the status is deallocated then turn it on with this sequence:
Server B
Server C
Server A
The Result will be:
Server A 192.168.0.3
Server B 192.168.0.1
Server C 192.168.0.2
If you turn off the VM from inside the VM, it won't be change the internal IP.
If you remote onto one of your VMs, you will see an XML file at
C:\config
The filename looks something like
[deployment id]_[role name]_[instance number].[version number]
Inside the file you will find all the instances in the deployment with their IP addresses. If you edit the IP address in this file for a particular role instance on a particular VM, that VM will think that the IP address for the instance is the one in the file and will start routing traffic to it.
Warning: I've never tried to do this programmatically. Also, the changes will get wiped out if there is any update to the deployment (either initiated by you or by Azure). And there might be some other horrible side effect.