MicroAd Developers Blog

マイクロアドのエンジニアブログです。インフラ、開発、分析について発信していきます。

トップ > インフラ > MAASを導入した話

MAASを導入した話

インフラ MAAS

f:id:yassan0627:20200911194126p:plain

こんにちは。マイクロアドでインフラエンジニアをしているハダです。
2回目にして久々のブログ執筆です。
今回の記事では、マイクロアドで利用を始めたCanonical社のMAASについて記事を書いていきたいと思います。
インストール方法や使い方などの詳細については公式ドキュメントを読んだほうが確実ですのでこの記事の中で触れていません。

背景

マイクロアドではPXE bootとkickstartを利用したOSインストールを、長年利用しています。
現在もその仕組は現役なのですが、今回はデータセンターの移設に伴ってMAASの導入を進めていくことになりました。

マイクロアドでの課題

マイクロアドではPXE BootとkickstartによるOSの自動インストールを行ってきました。
過去から引き継ぎ、より使いやすいようにしてきましたが以下のような課題も出てきました。

PXE Bootを利用したインストールの限界

kickstartについては知識がないと設定の編集がしづらい状況でした。
標準構成と異なるハードウェアにOSをインストールする際には、kickstartの設定を変えたりして対応する場合もあったり、
一方でCentOS以外にUbuntuを利用したいなどの話も出ており、対応方法について検討が必要な状況でした。

管理するサーバの増加と故障対応

マイクロアドでは物理サーバで千数百台のサーバを管理しています。
物理サーバが増えていくと、その分故障で停止するサーバも少なからず増えていきます。
HDDやSSDドライブの故障によりOSの再インストールが必要になる場合も多く、
その都度故障部品のパーツ交換を行い、PXE bootしOSインストールまでを現地で対応しています。

現地への駆けつけ

マイクロアドでは、IPMIの利用が進んでおらずサーバがリモートから操作できなくなると、現地での作業が必要になります。
データセンターのリモート保守サービスを利用して電源OFF/ONを実施したりしていますが、手配までには時間が掛かったり、連絡のやり取りが発生したりと復旧までに1時間位かかることがほとんどです。
また、故障の箇所によっては電源OFF/ONでは起動できず結局現地に行くことも。

MAASとは

Metal as a Serviceの略で、最近のMobility as a Serviceとは別物です…。
Metal = 物理サーバをクラウドのようなインタフェースで使うことを目的に作られた管理ツールです。
MAASを使うことにより、物理サーバのOSインストールや管理がまるでクラウドリソースを扱うように利用することが可能になります。

f:id:yassan0627:20200928113152p:plain
マシンの詳細

なお、MAASは物理サーバだけではなくKVMやVMwareなどのハイパーバイザー上の仮想マシン管理もできます。

OSも標準でUbuntuとCentOSをインストールできます。

f:id:yassan0627:20200928113846p:plain
CentOS7をインストールしたマシン

マイクロアドでMAASを導入したきっかけ

先程も触れましたが、マイクロアドではデータセンターを移設を進めています。
その中で、新しいセンターでは最低限IPMIを使って電源管理ができるようにしようという計画になっていました。

人は欲深くなるもので、電源管理以外にも遠隔で対応したいという思いが出てきました。
例えば

  • IPMIで電源管理だけじゃなく、OSのインストールとかも簡単にやりたいな…
  • CentOSだけじゃなくてUbuntuも使えるようにしたい…
  • 空いてるサーバがどれくらいあるかも簡単に知りたい…
  • 1〜2台のOS再インストールだけのために現地行きたくないよね…
  • でも1〜2台を遊ばせておくのももったいない…

そして昨今のコロナ禍において業務の殆どがテレワークになりました。
そのためオフィスよりも現地への駆けつけには時間がかかる可能性が高くなり、
よりリモートでサーバをコントロールできる状況にしていく必要がありそうという状況になってきました。

導入を進めてみて

新しいデータセンターの機器はほとんどMAAS管理できるようにしています。
裏を返すとすべてのサーバがIPMIでコントロールできる様になっており、
リモートからコンソール画面を確認したり強制的に電源をOFF/ONするなどの対応も行えるようになっています。

MAASの画面上では、ハードウェア構成や取得できる場合にはシリアル番号なども表示され、いちいちログインして確認したり購入時のハードウェア構成を調べたりする必要がなくなります。

故障時にパーツを交換しなければいけない点は変わりませんが、
現地での作業はパーツ交換のみにとどまり、通電してIPMIでの疎通が取れることが確認できると以降の作業はリモートから対応することができるようになりました。

OSのインストールだけではなくハングアップ時のコンソール画面の確認、
IPMIや管理コンソールを使ったハードウェアの確認など
MAASを導入したことによるメリットも多くこれからの運用管理に重宝していきそうです。

利用上の注意点

MAASの利用に際して、以下の点に気をつけておく必要があります。

  • MAASの無償版でデプロイできるOSは、UbuntuとCentOS6,7のみ
  • 冗長化の仕組みについては、別途検討が必要（特にDBの冗長化について）
  • 既存環境にあとからMAASを設定する場合は、すでにDHCPサーバがある場合は停止する
  • MAASで管理したいマシンの起動順序を必ずPXE bootを1番目にしておく
  • DHCP Relayで設定する場合、実際にDHCPをリレーするのはMAAS外で設定を行う必要がある

MAASをSNAPでインストールするススメ

MAASの公式ドキュメントにも記載がありますが、MAASをインストールする際にはsnapからインストールすることをオススメします。
channel=2.8のように指定してインストールすると、2.8系バージョンのアップデートをsnap側で定期的にチェックし、自動的に更新してくれるようになります。
メジャーバージョンのアップグレードは、snapのrefreshコマンドを使用しchannelをアップグレードしたいバージョンに指定するだけでバージョンアップが完了します。

簡単にバージョンアップが行えるので、いつの間にかバージョン古すぎて「アップグレードどうしよう…」ということがないようになるはずです。 マイクロアドでは2.7.0の時点でセットアップし、今は2.8.2が動いています。

終わりに

まだまだ移設が始まったばかりでもあり、MAASについては調整を進めながら利用しています。
IPMIの仮想コンソールがjavaクライアントしか対応できないサーバがあるので起動時のkernelオプションを設定したり、DHCP Relayを使用してラックコントローラを個別に配置せず設定しています。
今は大きなトラブルもなく利用できているので、更に使い込んで行きたいと思っています。
そのうえで今後は、MAASとJujuを使ってOpenStackやKubernetesなどの環境を整備していきたいと思っています。