CentOS 7の基礎

2014年11月14日(金)
古賀 政純

CentOS 7連載の第1回では、CentOS 7が選定される背景、採用されるサーバー基盤、アーキテクチャなどの基礎的な内容をご紹介します。

CentOS 7を利用する背景

2014年6月に発表されたRHEL 7の互換OSとして、CentOS 7が2014年7月にリリースされました。CentOS 7は無償提供されているサーバーシステム用のLinux OSです。CentOS 7は、CentOSのコミュニティのメンバーやRed Hat社の技術者達が開発に関わっています。レッドハット社は、Red Hat Enterprise Linux(通称RHEL)を構成するオープンソースソフトウェアのソースコードを公開しています。このソースコードを用いて、Red Hat社の商標や商用ソフトウェアを取り除いた形で1つのLinuxディストリビューションとしてまとめたものを「RHEL互換OS」といい、その一つにCentOSがあります。RHELの互換OSとしては、CentOS(Community ENTerprise OS)以外にも、科学技術計算サーバーで利用されるScientific LinuxやRocks Cluster Distributionなどが古くから存在します。

CentOSのコミュニティ発足当時は、RHEL互換OSという立場から、レッドハット社によるCentOSの発展には関与しない形でしたが、2014年から、CentOSプロジェクトをレッドハット社が支援する形になりました。2014年4月にサンフランシスコで開催されたRed Hat Summit 2014では、CentOSのコミュニティがブースを出展しており、Red Hat社の協調拡大路線がうかがえます。

図1:Red Hat Summit 2014におけるCentOS展示ブース。CentOSコミュニティとRed Hat社エンジニアが協調路線をとっている(クリックで拡大)

CentOS 7連載の第1回では、CentOS 7が選定される背景、採用されるサーバー基盤、アーキテクチャなどの基礎的な内容をご紹介します。

保守サポートとシステム構成の関係

CentOS は、誰もが無償で入手できるLinuxのディストリビューションです。しかし、CentOSは、ベンダーの保守サポートがありません。RHELやSLES等の商用Linuxを導入するユーザーは、ハードウェアとドライバーや監視エージェント類、ミドルウェアの問題の切り分け作業をベンダーに依頼できますが、CentOSには、ベンダーの保守サポートがありませんので、問題の切り分け作業をユーザー自身で行う必要があります。障害が発生しなくても、性能が劣化するような問題が発生した場合、ハードウェアに問題があるのか、カーネルパラメータの設定に問題があるのか、ミドルウェアのチューニングに問題があるのか等の切り分け作業は膨大な工数が伴う場合があります。その点を踏まえた上での適材適所の導入が重要です。

Linux OSの保守サポートの有無は、利用するシステムと密接な関係があります。Webサーバーのようなフロントエンド層では、スケールアウト型サーバーによって構成され、1台のWebサーバーに障害が発生しても、他のWebサーバーに負荷分散することによって全体に影響が出ない仕組みになっています。さらに、トラフィックの負荷分散を行うために、通常、Webサーバーは、大量にノードを配置します。このため、初期導入及び導入後のシステム拡張の運用費低減の観点から、OSにフリーLinuxを採用する場合が少なくありません。フロントエンドサーバーの場合は、負荷分散装置と、ある程度ノードの台数を多めに配置すれば、それほど厳密なチューニングをしなくてもWebサーバーとしての性能はスケールします。一方、データベース等のバックエンドサーバーには、大規模な基幹システムであれば、UNIXやNonstopシステム等のミッションクリティカルシステムが採用され、部門のデータベースサーバーにおいては、RHEL等の商用Linuxが採用されます。顧客の預貯金データの保管や、決済処理等の極めて厳密な整合性が要求されるトランザクション処理を行うデータベースシステムでは、障害発生時の問題切り分け作業、原因追究、復旧作業が顧客とベンダー双方にとって非常に重要な意味を持ちます。商用Linuxを採用することによる責任範囲の明確化があげられるでしょう。このため、バックエンドサーバーでは、RHEL等の商用Linuxが採用される傾向にあります。

このように、利用されるシステムやユーザー部門の技術スキル、SLA等によって、CentOS等のフリーLinuxや商用Linuxが適材適所に配置される事を忘れてはなりません。最近では、フロントエンドサーバーとして、CentOS以外にUbuntu Serverなどの利用も見られますが、Linux技術者の新しいスキル習得のコスト削減や保有スキルの有効利用の関係上、世界中のサービスプロバイダーのフロントエンドサーバーの多くはCentOSが採用されています。

図2:3層構成におけるCentOSの利用(クリックで拡大)

CentOS 7のアーキテクチャと利用シーンと注意点

CentOS 7は、32ビット版は廃止され、64ビットのx86_64アーキテクチャをサポートしています。32ビット版x86アーキテクチャのマシンを利用する場合には、CentOS 4、CentOS 5、CentOS 6系を利用する必要があります。また、IBMメインフレーム、Alphaアーキテクチャ、SPARCアーキテクチャ、IA-64アーキテクチャは、CentOS 4までのサポートであるため、これらの64ビット非x86アーキテクチャを利用する場合には、CentOSのバージョンに注意が必要です。さらに、CentOSは、現時点でARMアーキテクチャをサポートしていません。

図3:2014年9月時点で、CentOS 7は、x86_64アーキテクチャに絞ったディストリビューションであることがわかる(クリックで拡大)

CentOS 6では、対応する論理CPU数が、最大64でしたが、CentOS 7になり、CentOS 5と同様にサポートされる最大論理CPU数が160になりました。現在、x86アーキテクチャのサーバーにおいて、マルチコアCPUのシステムで64コアを超える利用も珍しくなくなりました。仮想化技術の普及と、クラウド基盤の導入が進んでおり、ホストOS上で稼働する仮想マシンごとに論理CPU を割り当て、同時に稼働させる仮想マシンの数が増えてきたことが背景にあります。

図4:CentOS 7では、最大160の論理CPUをサポートする。比較的中規模から大規模のSMPマシンを使用した仮想化システムにおいて大量のコアを同時に仮想マシンに割り当てるニーズが背景にある(クリックで拡大)

CentOS 7でサポートされる最大メモリ容量は、CentOS 6と同様に3TBで変わりありません。最近のx86_64アーキテクチャのハイエンドのSMPマシン(HP ProLiant DL580 Gen8等)では、最大メモリ搭載容量が6TB程度のものも登場しています。現時点でCentOS 7でサポートされる容量は3TBですが、理論的には64TBまで利用できる可能性があります。

図5:CentOS 7は、CentOS 6と同様に3TBまでのメモリ容量をサポートする(クリックで拡大)

CentOSでは、ファイルシステムとして、ext3、ext4に加え、XFSがサポートされ、最大ファイルシステムサイズも500TBをサポートしており、ビッグデータ分析基盤での利用が想定されます。近年、ビッグデータ用途向けに開発されたサーバーは、1筺体あたり4TBのハードディスクを60本搭載できるモデル(ビッグデータ基盤向けサーバーとしてはHP ProLiant SL4540 Gen8等)も登場しています。

このようなビッグデータ向けに開発されたx86サーバーでは、1筺体で、内蔵ディスクが200TBを超えることも少なくないため、ext4に取って代わるファイルシステムの利用が期待されていました。今回、CentOS 7で、XFSが標準でサポートされるようになり、ビッグデータ基盤への対応が進みました。CentOS 7は、BIOSを搭載したサーバーだけでなく、UEFI(Unified Extensible Firmware Interface)への対応など次世代サーバー基盤を見据えたアーキテクチャになっており、CentOSコミュニティは、引き続きサーバープラットフォーム用のOSに特化した取り組みを行っています。UEFI搭載マシンは、OSのブートの仕組みが従来のBIOS機と大きく異なるため、注意が必要です。例えば、CentOS 6におけるBIOS搭載マシンのブート領域(最大ブートLUNサイズ)は、ハードディスクの2TB未満に配置する必要がありましたが、EFI搭載マシンにではその制限が設けられていませんでした。しかし、CentOS 7では、EFI搭載マシンの場合に、2TBの制限が撤廃されているものの、ブート領域を50TB以内に配置しなければならない制限が設けられています。サポートされる論理CPU数やメモリ容量、ファイルシステムサイズ等は、CentOS 7になり大幅に最大値が引き上げられています。

図6:CentOS 7は、XFSが標準でサポートされ、500TBまで利用できるようになった。大容量の内蔵ディスクを大量に使うHadoopクラスターのようなビッグデータ基盤に適したファイルシステムを利用することができる(クリックで拡大)

CentOS 7でサポートされる論理CPU、メモリ容量、ファイルシステムサイズ等の上限は、CentOS 7のアップストリームに位置づけられるRHEL 7の制限値が参考になります。

Red Hat Enterprise Linux 7のリリースノートに掲載されている制限値

また、CentOSプロジェクトの「CentOS Product Specifications」のWebページに、バージョン毎の制限値が掲載されていますので、更新されていないかのチェックも含め、参照するようにしましょう。

CentOS Product Specifications

スケールアウト型基盤におけるフリーLinux採用の背景

2014年秋以降、米国HPをはじめとする主要なハードウェアベンダーにおいて、RHEL 7及びその互換OSであるCentOS 7が稼働できるx86サーバーが続々とリリースされています。x86サーバーの製造を手掛けるベンダーがRHEL 7の動作認定だけでなく、その互換OSであるCentOS 7の動作確認(動作認定ではないことに注意)に取り組む背景には、近年のスケールアウト型システムを導入するホスティング/Web・クラウドサービスやオンラインゲームサービス、そしてHadoopクラスター等のビッグデータ基盤のニーズが大きく影響しています。

スケールアウト型サーバーを購入するサービスプロバイダーやHadoopユーザーの多くは、最新技術でありながらも、安定したオープンソースソフトウェア(以下OSS)を採用し、数百台、数千台レベルのサーバーへの導入と運用の簡素化を求めています。スケールアウト型システムを採用するサービスプロバイダーやHadoopユーザーの場合、最初はスモールスタートでサーバー台数が少ない場合でも、システムの拡張に伴いサーバー台数が増える傾向にあります。その場合の導入費用の圧縮を図るために、CentOSが利用される傾向にあります。ただし、ユーザーの1次保管庫に利用されるような分散ストレージ基盤(GlusterFSやCeph等のオープンソースソフトウェアと複数のサーバーノードを駆使したストレージシステム)は、顧客の重要なデータを保管しておくというシステムの特性上、商用LinuxやRed Hat Storage等の商用の分散ストレージソフトウェアを採用する傾向にあります。技術的に、CentOS上で分散ストレージを実現するオープンソースソフトウェアを稼働させることは可能ですが、SLAや障害発生時の問題切り分けの体制、責任範囲を明確に定義しておく必要があります。

図7:スケールアウト型の分析基盤では、UNIX、商用Linuxではなく、CentOS等のフリーLinuxが採用される傾向にある。スケールアウト型でも分散ストレージ基盤では、データの保全性とサポートの必要性の観点から、商用製品の採用が検討される傾向にある(クリックで拡大)

CentOS 7のリリースサイクル

CentOSは、ベンダーによる保守サポートはありませんが、コミュニティによるメンテナンスの更新の期限が存在します。CentOSにおけるメンテナンスの更新は、2種類存在します。新機能の追加やセキュリティ対策用のパッチのリリースが行われる「完全更新(Full Updates)」と、最低限必要とされるセキュリティ対策用のパッチのリリースを想定した「メンテナンス更新(Maintenance Updates)」です。

CentOS 7の場合、メンテナンス更新として約10年を想定しており、その10年間の間に、完全更新は、1年に数回程度の実施されることを想定しています。CentOS 4のメンテナンス更新期限(End-of-Life)は2012年にすでに終了しています。CentOS 5のメンテナンス更新期限は2017年3月31日を想定しているため、現状、CentOS 5でシステムを構成している場合は、2017年までに対策を打つ必要があるでしょう。CentOS 6のメンテナンス更新期限は2020年11月30日、CentOS 7のメンテナンス更新期限は2024年6月30日となっています。

図8:CentOSのコミュニティが定める完全更新の期限とメンテナンス更新期限。CentOS 7は、2024年まで最低限必要なセキュリティパッチの提供が行われる予定である(クリックで拡大)

CentOSのメンテナンス更新期限は以下のURLで確認することができます。アプリケーションの対応の関係上、CentOS 7ではなく、CentOS 6を導入せざるを得ない場合がありますが、その導入を予定しているシステムの更改時期とCentOSのメンテナンス更新期限を照らし合わせてCentOSの導入の検討を行うようにしましょう。

CentOSのメンテナンス更新期限

CentOSのバージョン

CentOS 6までは、バージョン番号として、メジャーバージョンとマイナーバージョンの組合せによって表記していました。例えば、メジャーバージョンが6で、マイナーバージョンが5の場合は、CentOS 6.5と表記していました。このメジャーバージョンとマイナーバージョンの組合せは、アップストリームであるRHELのバージョンに対応しており、対応するRHELのバージョンと互換性を保つようになっています。CentOS 7では、メジャーバージョンとマイナーバージョンにリリースされたソースコードの年月を意味するタイムスタンプが付与される表記になりました。例えば、CentOS 7の場合、RHEL7.0をベースに、2014年6月にリリースされたソースコードを基にしているため、CentOS 7.0.1406というバージョンになります。

CentOS 7のカーネルの新機能

CentOS 7は、Linuxカーネルバージョン3.10.0の採用によりテラバイトクラスの大規模メモリへの対応が図られており、テラバイトクラスのメモリを搭載した場合のkdumpにも対応しています。アップストリームのRHEL7において、テクノロジープレビューではあるものの、複数のCPUに対応したクラッシュカーネルの起動にも対応しています。最近のマルチコアCPUのサーバーで採用されているNUMAアーキテクチャを持つシステムにおいて、アプリケーション等のプロセスの配置を自動的に行い、性能改善を試みる機能も搭載されています。OSのスワップメモリを圧縮する技術である「zswap」により、ディスクI/Oを低減し、性能向上を試みる仕組みが搭載されています。

CentOS7の目玉機能の一つとしては、「稼働したままカーネルのパッチ適用が可能」という点です。これは、ダイナミック・カーネル・パッチング(通称kpatch)と呼ばれます。Oracle Linuxのkspliceや、SUSE系ディストリビューションに搭載されているkGraftに相当するものです。OSを再起動せずにカーネルにパッチを当てることができるため、ダウンタイムの大幅な削減に貢献します。ただし、アップストリームであるRHEL7では、あくまでテクノロジープレビューでの搭載ですので、CentOS 7でも同様にテクノロジープレビューの範囲での利用に留めておくべきです。

kpatchの参考情報

CentOS 7に搭載されているkpatchと同様の機能で、RHELクローンの一種であるOracle LinuxにおいてOSを再起動せずにパッチ適用を実現するkspliceの機能は、コミュニティが手掛けるアップストリームカーネルに取り込まれるか否かが非常に重要になってきます。過去、kspliceは、構造が複雑過ぎる等の理由で、アップストリームカーネルへの導入を拒否されています。しかし、再びアップストリームカーネルへの採用も検討されているようですので、今後、アップストリームカーネルへのksplice、kpatch、kGraftの採用競争が繰り広げられる可能性があります。

kpatchのまとめ

  • ミッションクリティカル顧客向けのゼロダウンタイムの実現に向けた取り組み
  • 稼働中のカーネルにパッチを当てるニーズがある
  • ftraceに基づくアーキテクチャ
  • カーネルモジュールまたはカーネルの修正を稼働中のカーネルに挿入

まとめ

第1回では、CentOS 7の概要について述べました。以下、CentOS 7のポイントを挙げておきます。

  • CentOSのコミュニティとRed Hat社が協調
  • 3層構成においては、CentOSの適材適所の見極めが重要
  • ビッグデータ基盤用に開発されたサーバーでの利用にも耐えられるXFSの採用
  • スケールアウト基盤導入顧客では、初期導入費用削減にCentOSを採用
  • 採用前に、CentOS 7における完全更新とメンテナンス更新の期限を知っておく
  • 稼働状態でパッチを適用するkpatch等のエンタープライズ向け機能の成熟が期待される
この連載が書籍になりました!
CentOS 7実践ガイド

古賀 政純 著
価格:3,000円+税
発売日:2015年2月25日発売
ISBN:978-4-8443-3753-9
発行:インプレスジャパン

CentOS 7実践ガイド

本書は、CentOS 7を取り巻く市場動向、CentOS 7が利用されるサーバーシステムの選定、CentOS 7の基礎、システム設計、OS管理やCentOS 7に対応したアプリケーションサーバーの構築手順などの勘所をご紹介します。連載では書ききれなかった本の内容、見どころが満載!

  • セキュリティ管理
  • チューニング
  • 自動インストール
  • Hadoop構築
  • GlusterFS
  • Ceph

Amazon詳細ページへImpress詳細ページへ

日本ヒューレット・パッカード株式会社 プリセールス統括本部 ソリューションセンター OSS・Linux担当 シニアITスペシャリスト

兵庫県伊丹市出身。1996年頃からオープンソースに携わる。2000年よりUNIXサーバーのSE及びスーパーコンピューターの並列計算プログラミング講師を担当。科学技術計算サーバーのSI経験も持つ。2005年、大手製造業向けLinuxサーバー提案で日本HP社長賞受賞。2006年、米国HPからLinux技術の伝道師に与えられる「OpenSource and Linux Ambassador Hall of Fame」を2年連続受賞。日本HPプリセールスMVPを4度受賞。現在は、Linux、FreeBSD、Hadoop等のOSSを駆使したスケールアウト型サーバー基盤のプリセールスSE、技術検証、技術文書執筆を担当。日本HPのオープンソース・Linuxテクノロジーエバンジェリストとして講演活動も行っている。Red Hat Certified Engineer、Red Hat Certified Virtualization Administrator、Novell Certified Linux Professional、EXIN Cloud Computing Foundation Certificate、HP Accredited Systems Engineer Cloud Architect、Red Hat Certified System Administrator in Red Hat OpenStack、Cloudera Certified Administrator for Apache Hadoop認定技術者。HP公式ブログ執筆者。趣味はレーシングカートとビリヤード

連載バックナンバー

Think ITメルマガ会員登録受付中

Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。

Think ITメルマガ会員のサービス内容を見る

他にもこの記事が読まれています