Ubuntu Weekly Topics

2012年5月18日号 UDS-Q(2)・aptの機能強化・Jujuのリソースマップ・OpenStackのHA化12.04の注意点(3)・UWN#265

この記事を読むのに必要な時間:およそ 3 分

UDS-Q(2)

先週に引き続き,今週もUDS-Qで話し合われたアイデア(のうち,筆者が気になったもの)を見ていきましょう注1)⁠今週は「Cloud」⁠Server」⁠Security」カテゴリに属する話題です。

注1
UDSで話し合われるのはあくまで「実装アイデア」で,そもそもアイデアの時点(UDSでの話し合いと,その後のML等での合意形成)で賛同を得られないケースや,アイデアそのものが受け入れられても,結局実装が行われないこともしばしばあります。⁠こういう機能が12.10に実装されるかもしれないと考えておくのが安全です。なお,UDSでは影も形もなかった(後出しで考えるとキーノートで若干触れられていたと言えなくもない)隠し玉が搭載されることもしばしばで,これが12.10のすべてというわけでもありません。
  • servercloud-q-apt-improvements:システムの自動運用やJuju・MaaSによるデプロイにおいて,aptを人間の手を煩わせずに使えるようにしよう。proxy経由で利用した時の信頼性を向上させよう。たとえば,アーカイブサーバーでインデックスとコンテンツが別々に更新されてしまった場合に「Hash sum mismatch」が返されないようにしよう。これはDebianのアーカイブ構成の問題でもあるので,Debianと連携して解決するべきだ。ファイル単位でハッシュを取ることで,⁠まとめて署名」するやり方から脱却した方がいい。
  • servercloud-q-juju-resource-map:Jujuの利用において,⁠特定の仮想マシンでしか機能しない」という状態は使い勝手が悪い。いろいろなマシンで利用できるようになるべきだ。しかし,マシンがどのようなスペックを持っているのかを知るための統一された方法がない。リソース問い合わせのためのAPIを作って解決するべきだ。
  • servercloud-q-openstack-ha:OpenStackを冗長構成にできるように,足回りを含めて準備をすべきだ。SPoFが存在する仮想化基盤はナンセンスだ。
  • servercloud-q-eucalyptus:Eucalyptus 3.1(オープンソース版)の取り込みと,3.0(商用版)へのコマンドラインツール(euca2ools)の対応を行おう。
  • servercloud-q-xen:Xen 4.2の対応と,ドキュメントの整備(特にネットワーク周り)と,Jujuとの連携を行おう。XCPのサポートも強化しよう。
  • servercloud-q-openstack-deployment-on-arm:OpenStackをARM上で利用できるようにしよう。
  • servercloud-q-mysql-roundtable:MySQLのリリース方針の変化への追従方法を考えよう。DebianやUbuntuの「最低限のセキュリティ修正だけを提供する」モデルは,Oracleがパッチに関する情報を提供してくれないので困難になってしまった。MySQLの今後のリリース方針と,MariaDBの現状をあわせて考え,よいアプローチを考えよう。10.04の5.1もまだまだサポートしなくてはならない。
  • servercloud-q-juju-release-process:JujuのCharmのリリース方針を検討しよう。2ヶ月に一度リリースしていくことを目標にプランを立ててみよう。
  • servercloud-q-maas-next-steps:MAASの新バージョンについて検討しよう。電源管理の自動化・自動的なハードウェアのバーンインテスト・インストールの高速化などなど,やることはたくさんある。
  • servercloud-q-apport-enhancements:サーバーベンダー向けにApportを拡張しよう。たとえばメモリ障害が起きた時に,ベンダーのサポート窓口が必要なログはたくさんある。それらを簡単に取得できるようにApportを拡張し,ログをやりとりしやすくしよう。
  • servercloud-q-powernap-opencompute-integration:PowerNapが特定のプロセスだけでなく,各種負荷状態のモニタリングをもとにトリガできるようにしよう。
  • servercloud-q-openflow-controller:Ubuntu環境で利用できるOpenFlow Controllerを選定しよう。
  • security-q-openjdk:OpenJDKをメンテナンスしていく方法を検討しよう。コードベースそのものをメンテナンスするにも,Red HatやSUSEと共同で作業していくべきだ。連携できないか確認し,より適切な方式で作業しよう。

12.04の注意点(3)

先々週から引き続き,12.04の利用上の注意をお届けします。今回は「アップグレードに伴う注意」です。

10.04からのアップグレードは検討が必要

現時点(2012年5月)において,10.04から12.04へのアップグレードは「12.04.1まで待つことを推奨」というステータスです。リリースノートを確認すると分かりますが注2)⁠10.04からのアップグレードには実際に複数の問題が残っており注3)⁠現状ではまだ「待ち」のステータスです。特に,SSH越しのリモート操作でのアップグレードは再起動後に致命的な結果をもたらす可能性があるため,十分に注意して行うべきです。

注2
この記述は「12.04リリースの翌々日」に追加される形で行われたため,リリース当日等の早い段階でリリースノートを確認していた場合,見逃している可能性があります。
注3
Alternate CDを用いたアップグレードに失敗する可能性がある・アップグレード後の再起動時にコンソール操作を行い,GRUBのエントリを手動で変更する必要がある,という2点が代表的な問題です。

12.04にはEucalyptusが含まれていません

サーバー関連の最大のポイントがこれです。12.04にはEucalyptusと,EucalyptusをベースにするUEC(Ubuntu Enterprise Cloud)が含まれていません。UECベースのプライベートクラウド環境を構築していた場合,OpenStackベースのUbuntu Cloud Infrastructureへ移行する必要があります。基本的な操作性はAWSOMEによって「EC2互換」として近似していますが,ノード設計は異なるものであり,相当な考慮が必要です。UEC環境が存在する場合は10.04に留まり,12.10以降の状況を確認していくのが安全です。

PPA等の非公式リポジトリを導入している場合の注意

非公式なリポジトリからパッケージを導入した11.10,あるいは10.04環境をアップグレードする場合,⁠導入したパッケージ」のバージョン文字列によっては,⁠非公式リポジトリ由来のパッケージを一度削除し,公式なパッケージに置き換える」⁠アップグレード後に非公式リポジトリを追加しなおす」といった対処が必要になる可能性があります。

代表的な問題は,次のようなメカニズムで生じます。

まず,非公式リポジトリから提供されるパッケージAのバージョン文字列に,⁠2.0」というものが入っている一方で,公式なリポジトリからは「1.1」が提供されている,という状態を仮定します。ここからアップグレードにより,公式なリポジトリから「1.2」が提供されるとします。

このような状態でアップグレードを行った場合,通常のアップグレードで提供される「1.2」「2.0」よりも古いとみなされるので,アップグレード後も「2.0」の非公式パッケージが残留します。これそのものは問題ありません。しかし,ライブラリの依存関係やビルド時にリンクされるライブラリによっては,公式リポジトリの「1.2」は新しい環境でビルドされたものなので正常に動作することが期待されますが,⁠2.0(ただし古いバージョンのUbuntuでビルドされたもの)⁠は,アップグレード後には正常に動作しない可能性があります。これにより,2.0」を一旦削除する』か,あるいは『⁠2.0(の新しいバージョンのUbuntuでビルドされたもの)⁠を導入する』必要がある,という状態に陥ります。12.04へのアップグレード後,奇妙な挙動に悩まされている場合は,アップグレード前に非公式リポジトリを追加していないか確認する必要があるでしょう。

UWN#265

Ubuntu Weekly Newsletter #265がリリースされています。

その他のニュース

注4
七桁も問題がある!という考え方もできますが,どのようなシステムにも問題はつきものなので,バグ登録が行われることそのものは良いことです。ただし,Launchpadに登録された「バグ」にはスパム的なものも含まれているため,どれぐらいが実効的なものなのか,という点では若干の疑問は残ります。
注5
挙動は相応に微妙です。……しかしながら,なにか物凄い勢いでパッチが投稿されており色々となんとかなってしまいそうな気配です。

著者プロフィール

吉田史(よしだふみひと)

Ubuntu Japanese Team Member株式会社創夢所属。システム管理を中心にWindows/PC Unixを併用している。Ubuntu Japanese Teamではパッケージサーバの管理や翻訳などの作業を担当。

コメント

コメントの記入