4 avg. rating (80% score) - 5879 votes
Attending interviews for pacemaker job? Need interview questions. Checkout our job interview questions and answers page framed here are to give you right information on the pacemakers to crack the interview in reputed companies.The pacemaker is a cluster resource manager that is dedicated to achieving maximum availability for the cluster resources by detecting the failures from nod and resource level by using messaging and membership capabilities provided by cluster infrastructure. To attend the job interview in the field, you should get information types of clusters, their functionalities and much more. If you are the one looking for such pacemaker job interview questions and answers then wisdomjobs.com job portal could be your right destination. Have a look for better career path.
Pacemaker is a cluster resource manager. It achieves maximum availability for your cluster services (resources) by detecting and recovering from node and resource-level failures by making use of the messaging and membership capabilities provided by your preferred cluster infrastructure (either Corosync or Heartbeat).
Pacemaker's key features include:
Pacemaker supports practically any redundancy configuration including Active/Active, Active/Passive, N+1, N+M, N-to-1 and N-to-N.
Pacemaker is composed of four key components :
The CIB uses XML to represent both the cluster's configuration and current state of all resources in the cluster. The contents of the CIB are automatically kept in sync across the entire cluster and are used by the PEngine to compute the ideal state of the cluster and how it should be achieved.Pacemaker centralizes all cluster decision making by electing one of the CRMd instances to act as a master. Should the elected CRMd process (or the node it is on) fail… a new one is quickly established.
STONITH is an acronym for Shoot-The-Other-Node-In-The-Head and is usually implemented with a remote power switch. In Pacemaker, STONITH devices are modeled as resources (and configured in the CIB) to enable them to be easily monitored for failure.
crm_mon utility is used to display the current state of an active cluster. It can show the cluster status by node or by resource and can be used in either single-shot or dynamically-updating mode. There are also modes for displaying a list of the operations performed (grouped by node and resource) as well as information about failures.
Using crm utility we can change the cluster resources as show in the below example:
crm configure property stonith-enabled=false; (disabled stonith i.e fencing resource)
crm configure show
crm configure show xml
crm configure primitive ClusterIP ocf:heartbeat:IPaddr2 params ip=192.168.122.120 cidr_netmask=32 op monitor interval=30s 192.168.122.120 is the floating address, we have given the imaginative name ClusterIP and tell the cluster to check that its running every 30 seconds.The other important piece of information here is ocf:heartbeat:IPaddr2, This tells Pacemaker three things about the resource you want to add. The first field, ocf, is the standard to which the resource script conforms to and where to find it. The second field is specific to OCF resources and tells the cluster which namespace to find the resource script in, in this case heartbeat. The last field indicates the name of the resource script.
crm ra list ocf pacemaker & crm ra list ocf heartbeat.
STONITH is an acronym for Shoot-The-Other-Node-In-The-Head and it protects your data from being corrupted by rogue nodes or concurrent access. Just because a node is unresponsive, this doesn’t mean it isn’t accessing your data. The only way to be 100% sure that your data is safe, is to use STONITH so we can be certain that the node is truly offline, before allowing the data to be accessed from another node.
STONITH also has a role to play in the event that a clustered service cannot be stopped. In this case, the cluster uses STONITH to force the whole node offline, thereby making it safe to start the service else where.
The Corosync Cluster Engine is an open source project Licensed under the New BSD License derived from the OpenAIS project.CoroSync contains the infrastructure (such as interprocess communication and network protocols) that used to be part of OpenAIS.
As the name of the project suggests, the purpose of Pacemaker high-availability clustering is to make sure that vital resources receive increased availability. Without a clustering solution, a service may fail at the moment the server crashes. If the service is configured as a resource in Pacemaker clustering, Pacemaker ensures that the service will still be available, even if a server in your network fails.
You need at least two servers that run Linux. Currently, Pacemaker is able to support up to 16 servers, but some people run it on clusters that have hundreds of servers, which are called nodes in the cluster. Virtually all Linux distributions are supported. But if you need Enterprise support, Novell's SUSE Linux Enterprise Server is currently the only Linux distribution that has that ability. The servers must be installed in the same LAN and, in most cases, a storage area network (SAN) is required as well. For optimal performance, you need a special device that is capable of shutting down a server if needed -- the STONITH device.
Clustering is about increased availability of services. To reach this goal, a service must be able to run on all servers in a cluster. The server must also be able to access its configuration files and data when it moves over to another server. To make this easy, I highly recommend using a SAN. Just put the data and configuration files on the SAN and make sure all servers can reach the SAN. If you can't install a SAN, there is another solution that offers shared access to the files. This could be a Network File System-based solution or a synchronization solution, such as rsync. If your data is not too dynamic, you could even schedule a cron job to keep the data and configuration in sync.
Imagine that a communication link fails in a two-node cluster. Both servers may think the other one is down and begin servicing the resource that you want to be highly available. If this resource needs access to the shared file system on the SAN, you may end up with a situation where both servers try to write to the same file system at the same time. If you are using a file system like Ext3, XFS or Ext4, this will cause severe file system corruption. The STONITH device makes sure that one of the servers is really shut down before a server can take over a resource from another. It does that by cutting the power to the server so it really is down. This sounds like a strange solution, but it's much better than having file system corruption.
You can do that if you are using a special purpose cluster file system. Currently, there are two of them: the Oracle Cluster File System (OCFS) 2 and the Global File System. Both are open source, so you can choose whichever system you prefer. If, however, you are creating your cluster on Red Hat Linux, you'll most likely work with GFS, which Red Hat developed. If you use Novell's SUSE, you will be working with OCFS2, because it is the only cluster-aware file system supported on SUSE. The special thing about these file systems is that they have a shared cache. That means if one server writes to the file system, the other server knows about it.
Pacemaker Related Tutorials
Pacemaker Related Interview Questions
|XML Interview Questions||Veritas Cluster Server (VCS) Interview Questions|
|Red Hat cluster Interview Questions||Oracle Real Application Clusters Interview Questions|
|Windows Clustering Interview Questions||Hadoop Cluster Interview Questions|
|Xml Publisher Interview Questions|
Pacemaker Related Practice Tests
|XML Practice Tests|
Old-school Development And Testing
Agile Development And Testing
From Waterfall To Evolutionary Development And Test
How To Test A System That Is Never Finished
Implementing An Agile Testing Approach
Agile Testing In A Remote Or Virtual Desktop Environment
Testing A Derivatives Trading System In An Uncooperative Environment
A Mixed Approach To System Development And Testing: Parallel Agile And Waterfall Approach Streams Within A Single Project
Agile Migration And Testing Of A Large-scale Financial System
Agile Testing With Mock Objects: A Cast-based Approach
Agile Testing – Learning From Your Own Mistakes
Agile: The Emperor’s New Test Plan?
The Power Of Continuous Integration Builds And Agile Deve- Lopment
The Payoffs And Perils Of Offshored Agile Projects
The Basic Rules Of Quality And Management Still Apply To Agile
Test-infecting A Development Team
Agile Success Through Test Automation: An Extreme Approach
Talking, Saying, And Listening: Communication In Agile Teams
Very-small-scale Agile Development And Testing Of A Wiki
Agile Special Tactics: Soa Projects
The Agile Test-driven Methodology Experiment
When Is A Scrum Not A Scrum?
Analysis Of The Case Studies
My Agile Process
The Roll-out And Adoption Of My Agile Process
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.