This slide has been presented in OpenStack summit Tokyo. This presentation has Overview of Masakari which is designed for Virtual Machine High Availability named Masakri.
https://www.openstack.org/summit/tokyo-2015/schedule/main-conference
Masakari has many kind of meaning depending on its context. First of all, I explain how we use the phrase ‘Masakari’ in our life.
Generally speaking, Masakari reminds us of ‘axe’ and/or KINTARO. KINTARO is a name of the Japanese fairy story and of its main character name.
In engineering context, we use phrase ‘まさかりをなげる’. Roughly translated “Throwing a Masakari”
This means “Point out a mistake in conferences or in their presentations.” Especially, it focuses on technically mistakes.
Finally, in OpenStack context “Masakari” means Virtual Machine High Availability service NTT developed.
This service rescues Virtual Machines when any errors occur for these.
This service is now available in Github. Check it out after this presentation.
Now, you’ve learned meaning of Masakari in OpenStack context, so it’s a good time to go.
We had 3 motivations for developing Masakari.
First of all, to enable pet type Virtual Machines & Application to work on OpenStack.
As you know pets vs cattle issue is under discussion long time in the community.
Ideally speaking from developer perspective, when we replace our Infra with OpenStack, the app on OpenStack should be cloud native application, which means that we should change App and the Infra at once.
However, in general it’s hard to accomplish because of their budget, release time or any reason.
We’ve developed Virtual Machine HA to change each app on OpenStack to cloud native step by step, even though we understand a bad way to introduce pets model to cloud.
That’s why we named this HA ‘Masakri’ we use in engineering context, which means ‘point out a mistake of ourself’.
Finally, we wanted to make‘Masakari’ open.
We’re deploying OpenStack in production, so we’d like to volunteer OpenStack in any way.
We think making “Masakari” open is one of our contribution.
From next slides, I’ll show you quick overview of ‘Masakari’.
We had 3 kind of requirements for Masakari.
1. Detect 3 types of VM down
2. Recover VM within few minutes.
3. Of course, this recovering works automatically
This is quick architecture overview of Masakari.
Masakari is roughly divided to 2 parts.
One is Masakari controller presented in light blue box at top of the slide. Another is state monitoring processes displayed in the boxes at bottom of the slide.
The controller process is in charge of calling OpenStack API depending on the type of notification from monitoring processes.
The monitoring processes are monitoring whether each type of error Masakari want to detect occurs or not.
In following slides, I’ll present you how each monitoring process is monitoring different errors.
As I mentioned before, the monitoring processes detect 3 types down.
These are ways to detect failures.
For detecting VM down, Masakari hooks libvirt’s event which is sent from libvirt.
For detecting manager process down, Masakari monitors whether manager processes works well or not.
For detecting host down, Masakari uses pacemaker.
I show you a quick instruction of Masakari.
Before setting up Masakari, there are 2 prerequisites,
Masakari assumes Compute Node uses KVM as its virtualizing technology and shares storages for ephemeral disks, NFS or ceph.
2.
Masakari doesn’t require its user to modify OpenStack.
It means everyone can start using Masakari into their OpenStack cloud.
The reason why we chose this way is that we’d like to upgrade OpenStack after new version of OpenStack is released.
OpenStack improves its feature in each releases, so we’d like to use new features as possible as we can.
Unfortunately, the more we change codes at one release, the more difficult we upgrade to new one.
We tried this challenge and accomplished.
Once again. Check the URL and send me if you have any question.
And then we have display in Market place S14. Please ask us in next booth.