I have three galera node with slave replication node it's smoothly running .But when i shutdown or reboot my machine then again want to restart my mariadb galera cluster but it is not start.please help
Related
I am a bit of a noob, and I am trying to install openstack (xena) on 3 debian machine, respectively named node1, node2 and node3.
By default, all those machines have a fixed ip address (in the dhcp server):
node1: 172.0.16.250
node2: 172.0.16.251
node3: 172.0.16.252
---
gateway: 172.0.16.2
mask: 255.240.0.0
---
dhcp server start->finish: 172.0.16.10 -> 172.0.16.249
My goal is to simply test openstack. I want to install the infra on node1, compute and storage on node2 & node3.
While following the installation procedure here, I have to add virtual network. The 3 computers only have 1 ethernet connection each. I use this configuration example for my nodes.
When restarting the node, I do not have any connection to internet anymore, nor to the local network.
I understand that I am doing something wrong, and I would like to contact internet from these machines, and contact them from any point in my LAN, so I can install openstack with ansible.
The steps I am following : https://docs.openstack.org/project-deploy-guide/openstack-ansible/latest/deploymenthost.html
If you are ruuning on Hypervisor like Virtualbox try to add a dedicated nat-mode interface for internet access. and multiple interface for your bridges like br-mgmt br-vxlan and ..
I got a kitchen-ansible test that runs serverspec as a verifier. The test runs on two containers. One running with Amazon Linux 1 and the other Amazon Linux 2. The Ansible code installs a Keycloak server which listens on the ports 8080 and 8443.
In the Amazon Linux 1 container, everything's fine and the serverspec reports the ports to be listening.
In the Amazon Linux 2 container, the installation also ends without any errors but serverspec fails to report the ports not be listening. As I found out Serverspec is wrong.
After logging into the container running netstat -tulpen |grep LISTEN it shows the ports to be listening. Serverspec is checking with ss command: /bin/sh -c ss\ -tunl\ \|\ grep\ -E\ --\ :8443\\\
So I logged in to the Amazon Linux 1 container for checking the output of the ss command there and it showed no listening on both ports.
So has anyone a clue why the serverspec succeeds on Amazon Linux 1 and fails on Amazon Linux 2 despite in both containers the ss command is reporting no ports to be listened on?
The root cause was, that the ports aren't bind quickly enough. Serverspec starts to check, when the service hasn't been started completely. Logging in to the container takes more time, so the service is started successful and the ports are bound.
Out of nowhere one of our API servers has started to fail with the following error:
http: TLS handshake error from 172.23.88.213:17244: EOF
It throws this error for every single node in the cluster, thus failing to start. This started happening this morning with no changes to any infrastructure.
Things I've tried that haven't helped:
Manually restart the weave docker container on the master node.
Manually kill and reschedule the api-server.
Manually restart the Docker daemon.
Manually restarted the kubelet service.
Check all SSL certs are valid, which they are.
Check inodes, thousands free.
Ping IP addresses of other nodes in cluster, all return ok with 0 packet loss.
Check journalctl and systemctl logs of kubelet services and the only significant errors I see are related to TLS handshake error.
Cluster specs:
Cloud provider: AWS
Kubernetes version: 1.11.6
Kubelet version: 1.11.6
Kops version: 1.11
I'm at a bit of a loss as to how to debug this further.
I have a deployment with 2 replicas of nginx with openconnect vpn proxy container (a pod has only one container).
They start without any problems and everything works, but once the connection crashes and my liveness probe fails, the nginx container is restarted ending up in CrashLoopbackoff because the openconnect and nginx restart fails with
nginx:
host not found in upstream "example.server.org" in /etc/nginx/nginx.conf:11
openconnect:
getaddrinfo failed for host 'vpn.server.com': Temporary failure in name resolution
It seems like the /etc/resolv.conf is edited by openconnect and on the pod restart it stays the same (altough it is not a part of a persistent volume) and I believe the whole container should be run from a clean docker image, where the /etc/resolv.conf is not modified, right?
The only way how to fix the CrashLoopback is to delete the pod and the deployment rc runs a new pod that works.
How is it different to create a new pod vs. when the container in pod is restarted by the liveness probe restartPolicy: Always? Is the container restarted with a clean image?
restartPolicy applies to all Containers in the Pod, not the pod itself. Pods usually only get re-created when someone explicitly deletes them.
I think this explains why the restarted container with the bad resolv.conf fails but a new pod works.
A "restarted container" is just that, it is not spawned new from the downloaded docker image. It is like killing a process and starting it - the file system for the new process is the same one the old process was updating. But a new pod will create a new container with a local file system view identical to the one packaged in the downloaded docker image - fresh start.
I successfully install OpenStack on real hardware with vitalization enabled, then I configure it to use KVM. However, when I run this command "nova hypervisor-show node1" on the compute node it show me this:
hypervisor_type: qemu
should it print KVM instead of qemu? and is there any way to make sure I am using KVM not pure qemu.
please note that I used fuel to deploy openstack environment.
This is a bug in the nova-client. Because kvm is still within the confines of qemu for openstack, it shows up as qemu whether it is kvm or not.
ref: https://bugs.launchpad.net/nova/+bug/1195361
You can do a ps aux on the node and see if you see a kvm process running.