Red Hat Enterprise Linuxを使う前に読む資料

Red Hat Enterprise Linux (RHEL)を使う前にサポート要件やライフサイクルの考え方、更新の案内、rpmパッケージ、SLAなどについてざっくりまとめた資料。 社内で新しく入社した人むけにまとめた資料。 一般にも便利そうなので公開します。もろもろ省略されているので正確な情報は各リンク先などを参照。

Red Hat Enterprise Linux を 使う前に読む資料 森若和雄 kmoriwak@redhat.com 2020-01-27 Red Hat K.K. All rights reserved. 1 agenda  認定・ライフサイクル・延長サポート製品  Red Hat Network, rpm, yum, errata  RPMパッケージの基礎  障害時の情報収集、サポート窓口、ケースの扱い  upstream first policy Red Hat K.K. All rights reserved. 2 認定・ライフサイクル・延長サポート製品 Red Hat K.K. All rights reserved. 3 各種認定の確認 サポートされる環境を整える   ハードウェアの認定 ● レッドハットによる認定 ● https://catalog.redhat.com/ ISV製品の認定 ● ISVによる認定 ● ●  Red HatではなくISV各社に確認 利用予定のアプリケーション開発ベンダへ動作環境をご確認頂く必要があります ストレージの認定 ● ストレージベンダによる認定 ● ● Red Hatではなくストレージベンダ各社に確認 利用予定のストレージベンダへ対応OSをご確認頂く必要があります Red Hat K.K. All rights reserved. 4 OEMRHELのサポートについて    レッドハットのRHELについてのサポートポリシーは今までの通 りですが、OEMRHELは異なることがあります OEMパートナが別途定めたポリシーによってサポート内容が決定 されます ● 特定ハードウェア上で動作することが必要 ● 特定パッケージはサポート対象外 など 詳細はOEM各社にご確認ください ● 「レッドハットの製品ではない」のでレッドハットは回答できません Red Hat K.K. All rights reserved. 5 RHELの製品ライフサイクル https://access.redhat.com/support/policy/updates/errata/ Red Hat Enterprise Linux versions 5, 6 and 7 Red Hat Enterprise Linux version 8 Red Hat K.K. All rights reserved. 6 RHELのリリース  メジャーバージョン、メジャーリリース (RHEL X) ● 例: RHEL4, RHEL5, RHEL6 ● 変更点: 基本的に別の製品(アップグレードは可能) ● ●   主要ライブラリについては互換のため1つ前の製品と同じ版を含む 頻度: およそ3年に1回メジャーリリースを出荷 アップデートリリース、マイナーリリース (RHEL X.Y) ● 例: RHEL5.7, RHEL5.8, RHEL6.3 ● 変更点: 新規パッケージの追加や機能拡張を含む ● 頻度: およそ半年に1回アップデートリリースを出荷 アップデートの途中で出荷される修正 (RHEL X.Y.Z) ● 変更点: 重要なセキュリティ問題やバグの修正。機能拡張は行わない ● 頻度: 特に回数は決まっていない Red Hat K.K. All rights reserved. 実際には 番号はつきません z-stream や 非同期errataと 呼ばれています 7 通常のRHELサポート  新しいアップデートリリースが出荷されると今までのアップデー トリリースのサポートは終了します ● ●  たとえばRHEL6.4が出荷されると、RHEL6.3までのバージョンはサポート対象では なくなります 利用そのものは問題ありません 古いアップデートリリース用の修正は出荷されません ● たとえばRHEL6.4で修正された問題について、「RHEL6.3用の修正がほしい」とリ クエストしても 「RHEL6.4で修正されているのでアップデートして対応してください」と回答しま す 時間 6.0 6.1 6.2 Red Hat K.K. All rights reserved. 6.3 6.4 8 RHEL開発ツリーとアップデートリリース RHEL6.5 6.0がメンテナンス されるのは 6.1が出荷されるまで 6 L E H R ツ 発 開 ー リ ( キ セ ィ テ リ ュ グ バ , fix 能 機 , fix 張 拡 ) RHEL6.4 RHEL6.3 RHEL6.2 RHEL6.1 6.1リリース RHEL6.0 QA期間 約6ヶ月 Red Hat K.K. All rights reserved. 時間 9 アップデートリリース間のアプリケーション互換性 「移行計画ガイド」からの抜粋 1.2. アプリケーションの互換性 (中略) Red Hat Enterprise Linux のマイナーリリース間ではアプリケーションの再テス トや再認定は必要ありません。 Red Hat Enterprise Linux の互換性ポリシーで は、 そのリリースの任意のバージョンで実行しているアプリケーションはそのリ リースのライフ期間中を通じて継続的に実行することを保証しています。 例え ば、 Red Hat Enterprise Linux 6.0 で認定されたアプリケーションは Red Hat Enterprise Linux 6.1 などの全マイナーリリースで完全な互換性を持つことになり ます。 ※上記はRed Hatのポリシーで、他社製ソフトウェアのサポート要件は各ISVによ り異なります。 https://access.redhat.com/knowledge/docs/ja-JP/Red_Hat_Enterprise_Linux/6/html/Migration_Planning_Guide/ch01s02.html Red Hat K.K. All rights reserved. 10 新機能導入   新機能はアップデートリリースとメジャーリリースのタイミング で導入 主要な新機能についてはドキュメント「Release Notes」で紹介 ● ●  RHEL 5,6では細かな違いの詳細についてはドキュメント「Technical Notes」で紹 介 サポート対象外の機能(テクノロジープレビュー)もこの文書で案内 製品ドキュメント ● https://access.redhat.com/knowledge/docs/ Red Hat K.K. All rights reserved. 11 新機能が入るタイミング RHEL6.5 ここまでの 変更を まとめて6.1に QAします 新機能 つくったよ 6 L E H R 6.1として 出荷 ツ 発 開 ー リ セ ( ュ キ ィ テ リ グ バ , fix 拡 能 機 , x fi ) 張 RHEL6.4 RHEL6.3 RHEL6.2 RHEL6.1 6.1リリース RHEL6.0 QA期間 時間 Red Hat K.K. All rights reserved. 12 重要な修正の導入   深刻なバグや、セキュリティ上の問題についてはアップデートリ リースを待たずに導入します 開発者が準備した修正を、現在サポート中およびQA中のリリー ス用に同梱します ● ほとんどの場合は同一のものですがアップデートリリースでパッケージのバージョ ンが異なる場合には複数バージョンで同一問題への対応がおこなわれます Red Hat K.K. All rights reserved. 13 重要な修正のタイミング RHEL6.5 6.2は最初から 対応済み 6.0, 6.1それぞれに 反映するよ E RH L6 ツ 発 開 ー リ 6.1は リリース時には 修正済み RHEL6.2 問題を なおしたよ RHEL6.4 RHEL6.3 RHEL6.1 6.0は 非同期errata 6.1リリース リリース RHEL6.0 QA期間 時間 Red Hat K.K. All rights reserved. 14 Extended Life-cycle Support(ELS)   RHEL 5(2020年11月まで), RHEL 6(2020年12月から) のサポート 期間を延長します 10年間の標準ライフサイクルに対して一部ソフトウェアのみサ ポート期間を延長 ●   ELSを購入しない場合、一切更新が行われないELP(Extended Life-cycle Phase)にな ります 通常のサブスクリプションに追加で購入するAdd-onサブスクリ プション サポート対象は限定的なので注意 ● https://access.redhat.com/articles/2901071 Red Hat K.K. All rights reserved. 15 Extended Update Support(EUS)    一部のパッケージについて、アップデートリリースのサポート期 間を24ヶ月に延長します(半年おきに出荷とすると18ヶ月延長) 延長された期間の間、以下がバックポートされます ● 重大影響度のRHSAと ● 一部の緊急優先度のRHBA 「アップデート実施回数の削減」が可能になります ● 例: 完全にサポートされた状態でRHEL6.0を使いつづけ6.1, 6.2をスキップしたのち 6.3へ移行 6.0 6.1 6.2 6.3 6.4 6.0 EUS 6.1 EUS 6.2 EUS Red Hat K.K. All rights reserved. 16 EUSの詳細  EUSが利用可能なマイナーバージョンはバラバラなのでRHELの ライフサイクルページを確認するのがよい ●  https://access.redhat.com/support/policy/updates/errata/#Extended_Update_S upport EUSで対象になるパッケージ ● RHEL 7 https://access.redhat.com/node/4082531RHEL 8 ● セキュリティfixはEOLになっていないパッケージのCriticalとImportant全て ● ● Application Stream等で非同期にEOLになるパッケージがある バグ修正は最低限以下が対象。これ以外もRed Hatの裁量で追加。 bind, bash, chrony, grub2, grubby, glibc, gnutis, kernel, libgcrypt, libvirt, nss, openssh, openssl, python 3.6, qemu-kvm, rpm, sudo, systemd, wget, yum / dnf Red Hat K.K. All rights reserved. 17 EUSでの修正提供 (RHEL6.2) RHEL6.5.z バグ直したよ RHEL6.4.z それぞれに 修正を 反映します 6 L E H R 発 開 リ ツ RHEL6.3.z ー EUSご購入のお客様のみ RHEL6.2.z RHEL6.2 EUS RHEL6.1.z 6.1リリース RHEL6.0.z QA期間 24ヶ月 Red Hat K.K. All rights reserved. 時間 18 EUSの必要有無   EUSが不要なケース ● ISVなどの要件がRHEL5, RHEL6 のようなメジャーリリースだけを指定している ● 機能拡張を含む更新を導入したい ● 修正が出てもソフトウェアの更新は一切おこなわない EUSが必要なケース ● ● ● ISVなどの要件が “RHEL 6.2” のようにアップデートリリースを指定する 機能拡張はしたくないが、深刻なバグとセキュリティ上の問題に対する修正は導入 したい 必要なソフトウェアがEUSでサポート対象になっている https://access.redhat.com/node/4082531 Red Hat K.K. All rights reserved. 19 古いマイナーリリースを使いつづけた場合のサポート  ポリシーが文書化され公開されています ●   ざっくりまとめると以下のようなポリシーです 「お客様には古いリリースを使う自由があります。ただし現在サ ポート対象となっているアクティブなリリースとの差分を埋める のはお客様の責任です。」 そのため、古いリリースを使いつづける場合は以下を検討します ●  https://access.redhat.com/articles/64664 問題が発生した場合にRHELの一部または全部を最新リリースへ更新して問題が再 現するか確認するための検証環境の用意 「更新しないでいい理由を探す」ことや「なぜ更新が必要かの説 明をする」ことはサポート窓口ではおこないません ● RHELは定期的に更新しつづけることが前提です。変則的な利用は禁止されていませ んがその支援は特に行いません。 20 Red Hat K.K. All rights reserved. Red Hat Network、rpmyum、errata Red Hat K.K. All rights reserved. 21 Red Hat Network とは   RHELおよび関連製品の管理・更新のための仕組み ● インストールに利用するISOイメージのダウンロード ● 個別rpmパッケージのダウンロード システムをRed Hat Networkに登録して以下のようなサービスを 利用する ● add-on製品などを必要なサーバに割り当て・インストール ● 追加・更新パッケージの取得 ● 各サーバのパッケージ状態の確認・管理 ● ● 状態を登録しないこともできます 利用中のシステムに関連する更新情報を通知・確認 Red Hat K.K. All rights reserved. 22 RHELの一般的な管理モデル システム管理 ソフトウェアの配布 アカウントの管理 サブスクリプションの管理  https Proxy Red Hat Networkを利用 ● インターネット接続を利用できる場合 ● 全サーバを rhsm.redhat.com に登録 ● 各サーバは cdn.redhat.com からパッケージを取得 ● Web UIはaccess.redhat.comから参照 Red Hat K.K. All rights reserved. 23 Red Hat Networkの用語  リポジトリ(repository) ● ●  rpmパッケージのセットをリポジトリと呼んでいる リポジットリには “Red Hat Enterprise Linux Server (v.6 for 64-bit x86_64” のよう な名前がついている ● 各システムはこのリポジトリを講読(subscribe)する ● yumコマンドで講読したリポジトリに含まれるrpmを取得できる サブスクリプション(subscription) ● どの製品を、いつからいつまでの期間、何本利用できるか ● 製品を購入すると、1つ以上のサブスクリプションが付与される ● システムが登録されるとサブスクリプションと対応づけられる(対応づけできないと 更新などのサービスを受けられない) Red Hat K.K. All rights reserved. 24 カスタマポータル(access.redhat.com) →サブスクリプション→システム Red Hat K.K. All rights reserved. 25 各システムのページ Red Hat K.K. All rights reserved. 26 非インターネット環境におけるRHEL管理モデル システム管理 ソフトウェアの配布 アカウントの管理 サブスクリプションの管理 オフライン Satellite ソフトウェアの配布  RHNと配布サーバの同期がポイント ● 完全にオフラインの場合: Red Hat SatelliteがRed Hat Network相当+αの機能を提供 ● Red Hat Smart Managementで提供 ● 自社専用Red Hat Networkを実現する別売り管理製品 ● 管理や自動化を支援する付加機能 ● Satelliteはデータをオンラインで同期できるほか、ISO形式で提供されるためオ フラインでの同期も可能 Red Hat K.K. All rights reserved. 27 rpmコマンドとyumコマンド  rpmコマンド ● rpmパッケージをインストール・削除・更新する ● ●  インストール時には依存関係を認識して不足パッケージがあれば通知 現在は主に情報収集やパッケージ内容の確認などに利用する yumコマンド ● 依存関係の自動解決を行いつつ、rpmパッケージを管理する ● パッケージの追加・削除をともなう管理はyumに集約する ● リポジトリ外のRPMパッケージをyumコマンドで導入する場合は以下のコマン ドラインを使用 ● yum localinstall URI ● 例) yum localinstal http://www.example.com/path/to/rpm/file.rpmyum localinstall path/to/rpm/file.rpm Red Hat K.K. All rights reserved. 28 アドバイザリの適用 RHEL 5 Server x86_64 ........... ........... ...........  5.4 ...........  ...........  ........... ........... ........... ........... ........... ........... 5.3 5.5 Errata アドバイザリの適用 = RHEL特有のソフトウェア保守作業 システムの健全性 (正確性、安全性、堅牢性) を保つため、最新 のアドバイザリの適用を推奨 アドバイザリの種類 (詳しくは後述): ● セキュリティ アドバイザリ ● バグ アドバイザリ ● 機能拡張 アドバイザリ Red Hat K.K. All rights reserved. 29 アドバイザリとOSアップデートリリースの関係   アップデートリリース: RHEL6.0 → 6.1 → 6.2... ● およそ6ヶ月毎のリリースサイクル ● ソフトウェアバージョンおよびAPI/ABIをできるだけ維持 アップデートリリースの実体 ● アドバイザリの集合 ● 以下の2つは基本的に全く同じもの*1 ● RHEL6.4 GA ● RHEL6.3にRHEL6.4時点のアドバイザリを適用したもの *1 実際にはRHEL6.4リリース日に提供される0dayエラータがあるのでぴったり合 わせることは難しい Red Hat K.K. All rights reserved. 30 アドバイザリとは   製品の修正や拡張は全てアドバイザリ(Advisory, errataとも)とよ ばれる形で提供される ● 各アドバイザリにはRPMパッケージが含まれる ● 一つのアドバイザリによって1つ以上の問題の修正に対応 ● あるアドバイザリはそれ以前のアドバイザリが全て適用された状態で検証済み 「パッチでの配布」との違い ● ● あるパッケージについて、特定の修正だけを選択的に適用する方法は無い 例: バグ修正が3回おこなわれたあとセキュリティ上の問題に対する修正がおこなわ れた。 セキュリティ上の問題に「だけ」対応したい→NG ● 検証するバリエーションが減る ● QAされたものだけを利用できる Red Hat K.K. All rights reserved. 31 アドバイザリ一覧の例: https://access.redhat.com/errata/ Red Hat K.K. All rights reserved. 32 アドバイザリの例: https://access.redhat.com/errata/RHBA-2020:0089 Red Hat K.K. All rights reserved. 33 アドバイザリの種別 と ID     セキュリティ修正 : Red Hat Security Advisory ● セキュリティに関する修正 ● 不定期に発行 バグ修正 : Red Hat Bug Advisory ● 不具合に関する修正 ● 不定期に発行 機能拡張修正 : Red Hat Enhancement Advisory ● 機能拡張に関する修正 ● OSのアップデートリリースで発行 アドバイザリのID = RHXA-YYYY : NNNN(-Z) ● X = S/B/Eのいずれか ● YYYY = アドバイザリの元となった問題の報告された年号 ● NNNN = 年毎の通し番号 ● Z = アドバイザリに修正がおこなわれた場合の識別子、通常はつかない Red Hat K.K. All rights reserved. 34 RHSA の影響度  Critical ●  このタイプの脆弱性は、ローカルユーザーによる権限の取得、認証されていないリ モートユーザーによる認証保護リソースの閲覧、認証されたリモートユーザーによ る任意のコードの実行、ローカルまたはリモートユーザーによるサービス拒否を可 能にします。 Moderate ●  このタイプの脆弱性は、ワームによる悪用が可能です。認証されたリモートユー ザー、ローカルユーザー、または非現実的な設定を必要とする不具合は、重大な影 響には分類されません。 Important ●  https://access.redhat.com/security/updates/classification/ このタイプの脆弱性は、重大または重要な影響になる可能性はありましたが、不具 合の技術評価に基づいてあまり容易に悪用できないか、非現実的な設定に影響しま す。 Low ● このタイプの脆弱性は、悪用のためにはあり得ない状況が必要と思われるものや、 悪用が成功しても影響は最小であるものです。 Red Hat K.K. All rights reserved. 35 RPMパッケージの基礎 Red Hat K.K. All rights reserved. 36 RPMパッケージとは 1/3  RPMパッケージ = インストールの最小単位 ● ●  RPMパッケージがインストールの有無を選択できる最小単位 目的や機能などでパッケージをまとめた「パッケージグループ」単位でのインス トールも可能 (インストーラおよびyumコマンド) RPMパッケージに含まれるもの: ● ● ● プログラムファイル、設定ファイル、データファイル等インストールされるファイ ル一式 インストール時、アンインストール時に実行されるアクション メタデータ (パッケージ名、バージョン、リリース、提供者、ビルドホスト 名、GPG Key、依存関係) Red Hat K.K. All rights reserved. 37 RPMパッケージとは 2/3 設定ファイル など プログラム、 ライブラリなど メタデータ パッケージ名、 バージョン、 説明、 依存関係など (RPM)パッケージ zlib-1.2.3-3.i386.rpm   その他データ パッケージ = プログラムやデータファイル等をまとめたもの + メタデータ RPMRHEL で採用されているパッケージ形式 ● RPM = RPM Package Manager ● http://rpm.org Red Hat K.K. All rights reserved. 38 RPMパッケージとは 3/3 RHN Web でのパッケージメタデータ表示例 パッケージ名 ● アーキテクチャ、バージョン ● 概要説明 ● 提供リポジトリ ● 変更ログ など ● Red Hat K.K. All rights reserved. 39 パッケージ vs. パッチ vs. アーカイブ 全データ メタデータ 名前 バージョン 説明 依存関係等 (簡易)メタデータ 差分データ (RPM) パッケージ 全データ 名前 バージョン 依存関係等 パッチ zlib-1.2.3-3.i386.rpm (tgz) アーカイブ zlib-1.2.3.tar.gz  パッケージは完全なデータ一式を含む  パッチは適用対象が必要  tar+gzip/zip アーカイブなどには通常はメタデータが含まれない ● アップデート/アンインストールが困難 Red Hat K.K. All rights reserved. 40 RHEL = RPMパッケージ集合 1/2 / ... usr/ ... share/ ... lib/ ... ... doc/ ... libz.so.* RHELシステ ム zlib-2.1.3/ zlib-1.2.3-3.i386.rpm FAQ README RHEL ファイルシステムRPM パッケージ RHEL システムは RPM パッケージに含まれるデータで構成され る Red Hat K.K. All rights reserved. 41 RHEL = RPMパッケージ集合 2/2 httpd-2.2.3-43.el5.i386.rpm mysql-5.0.77-4.el5.i386.rpm RHELシステム (コンポーネン ト構成の視点か ら) httpd mysql app1 zlib, etc. glibc Kernel app1-x.y.z-1.i386.rpm zlib-1.2.3-3.i386.rpm glibc-2.5-49.i686.rpm kernel-2.6.18-194.el5.i686.rpmRPM パッケージはRHEL システムを構成するソフトウェアコン ポーネントの基本単位 Red Hat K.K. All rights reserved. 42 バイナリRPMパッケージのインストール / usr/ lib/ ... ... ファイルの展開と配置 ... バイナリ RPM を インストール RHEL システム   RHEL ファイルシステム アクションの実行 インストール = ファイルの展開と配置 + アクションの実行 Kernel や glibc など核となるパッケージのアップデート時には更 新の反映のために、システムの再起動が必要 Red Hat K.K. All rights reserved. 43 バイナリRPMパッケージのアップデート / usr/ lib/ ... ... RHELシステ ム ファイルの展開と配置 (旧版の置き換え) ... より新しいバイナリ RPM をインストール RHEL ファイルシステム アクションの実行  アップデート = 旧版のアンインストール + 新版のインストール  ダウングレードについて ● ダウングレード = アップデートの逆、旧版による新版の置き換え ● 多くの場合可能だが、必ず可能ではない ● 非可逆なアクションの逆方向への実行はむずかしい ● 複雑な依存関係 (Obsoletes) があるとより困難 Red Hat K.K. All rights reserved. 44 RPMパッケージの基礎 まとめ   RPM パッケージは RHEL システムの基本単位 ● バイナリ/ソース/Debuginfo パッケージ ● サポート対象はバイナリ RPM のみ バイナリパッケージ = 静的データ + アクション ●  依存関係はシステムの整合性を保つため ●  RPM のインストール = ファイルの展開、配置 + アクション実行 無視してはだめです。最悪の場合システムが壊れます! パッケージのアップデート = 新規パッケージによる旧版の置き換 え ● 『パッチ』 は提供していません ● 必ずしもダウングレードは可能ではありません Red Hat K.K. All rights reserved. 45 障害時の情報収集、サポート窓口、ケースの扱い Red Hat K.K. All rights reserved. 46 障害対応の基礎  情報収集 ● 初期の問題切り分け ● ●  問題切り分けの有無と正確さにより、その後の対応速度に大きな差が出ます sosreport, kexec&kdump サポートケースのオープン ● カスタマーポータルもしくは電話にてケースオープン ※営業時間外でのケースオープン時にはカスタマーポータルでケース登録後に 電話での一報が必要 ● サポート担当者とのやりとりによる対応 Red Hat K.K. All rights reserved. 47 sosreport   各種ハードウェア/ソフトウェア環境情報を収集しアーカイブ ● /etc、/var/log 内の主要な設定とログ ● sosreport実行時の負荷状況取得 ● その他各種ソフトウェアに対応した設定情報・ログ取得 サポートチームが問題に対する前提条件をお客様と共有するた め、ケースオープンの初動としてsosreportの出力結果の送付を お願いする事が多くあります ●   ケースオープン時に"sosreport -a"の出力を添付しておくと早く対応開始できます 通常のtar ballなので送付前に秘密にしたい情報が含まれていな いかチェック可能です サポート問い合わせ時以外に、サーバの状態を記録する目的にも 応用できます Red Hat K.K. All rights reserved. 48 sosreport 実行例 # sosreport -a sosreport (version 2.2) This utility will collect some detailed information about the hardware and setup of your Red Hat Enterprise Linux system. The information is collected and an archive is packaged under /tmp, which you can send to a support representative. Red Hat Enterprise Linux will use this information for diagnostic purposes ONLY and it will be considered confidential information. This process may take a while to complete. No changes will be made to your system. Press ENTER to continue, or CTRL-C to quit. Please enter your first initial and last name [kmoriwak]: Please enter the case number that you are generating this report for: 12341234 Running plugins. Please wait ... Completed [55/55] ... Creating compressed archive... Your sosreport has been generated and saved in: /tmp/sosreport-kmoriwak.12341234-20130207155145-2178.tar.xz The md5sum is: b1add664051d3ddd1758f5f20a2d2178 Please send fileAll torights your reserved. support representative. Redthis Hat K.K. 49 sosreportの中身  各種状態確認コマンド出力、 /proc, /sys内容  各種ログ  設定ファイル  sarの監視情報  などなど boot chkconfig date df dmidecode etc free hostname ifconfig installed-rpms java lib lsb-release lsmod lsof lspci lvmdump mount netstat proc ps pstree root route rpm-Va sar07 sar31 sbin sestatus var sos_commands vgdisplay sos_logs sos_reports sys uname uptime Red Hat K.K. All rights reserved. 50 kexec & kdump     障害によってメモリダンプ解析が必要になる場合があります ● システムがpanicしてしまい、他に情報が残らない場合 ● カーネル内のバグが疑われる場合 RHELでは、kexec&kdumpと呼ばれる仕組みでメモリダンプを 取得します kexec ● カーネルが再起動をともなわずに別のカーネルをロード ● 本来は高速なリブートを実現するための仕組み kdump ● ダンプ専用カーネルを用意し、kexecを利用して実行 ● 再起動をともなわないためメモリの情報が残っている Red Hat K.K. All rights reserved. 51 サポートケースの新規作成 Red Hat K.K. All rights reserved. 52 作成したケースの確認 Red Hat K.K. All rights reserved. 53 サポートコールフロー Red Hat K.K. All rights reserved. 54 重大度レベル(シビリティ)   サポートへの問い合わせ時に、問題のビジネスインパクトにより 1(緊急)から4(低)までの範囲で重大度を設定する ● サポート対応時間に影響します ● 営業時間外に重大度1または2を登録する場合、ケース登録後にお電話ください https://access.redhat.com/support/policy/severity/ 以下は抜き書きです。正確な定義は上のURLに記載されています 重大度1 (緊急) プロダクション用途に深刻な影響を及ぼす問題。 業務を停止せざるを得ない状況 で、回避策がない。 重大度2 (高) プロダクション用途において、業務の一部に深刻な影響を与える状況で、回避策が ない。 重大度3 (中) プロダクション用途において、お客様のビジネスに中から低程度の影響があるが、 回避策があり、業務は続けられる場合。 開発用途において、プロジェクトを続行できない、またはプロダクションに移るこ とのできない状態。 重大度4 (低) 一般的な使用に関する質問、文書エラーの報告、将来の製品改善または修正の推 奨。 プロダクション用途において、システムの機能や性能、またはビジネスへの影 響が低い、もしくは無い。 開発用途において、ビジネスに中から低程度の影響があ Red Hat K.K. All rights reserved. るが、回避策があり、業務は続けられる。 55 重大度とSLA 重大度およびサポートのレベルにより対応時間のSLAが 変わります Standard 対象時間 営業時間 初期/継続応答時間 重大度1 重大度2 重大度3 重大度4 Premium 営業時間(重大度1と2の場合は24時間365日) 初期応答時間 継続応答時間 1営業時間 1時間 1 時間またはお客様との 合意による 4営業時間 2時間 4 時間またはお客様との 合意による 1営業日 4営業時間 8 営業時間またはお客様 との合意による 2営業日 8営業時間 2 営業日またはお客様と の合意による Red Hat K.K. All rights reserved. 56 サポート問合せ時に必要な情報 以下の情報をご用意下さい ● プロダクトID(サブスクリプション番号)または顧客番号 ● 会社名、ご担当者様のお名前 ● 連絡方法(電話/Web)、(電話でのご連絡をご希望の場合、電話番号) ● 関連する製品名とそのバージョン ● 問題の詳細な説明、重大性レベル(開発/本番環境、業務への影響有無、回避方法有無) 以下の情報があるとスムーズな対応が可能になります ● sosreport -aの出力 ● 問題の再現性の有無および再現手順 ● 問題を引き起こす可能性のある修正をシステムに対して行ったかどうか ● エラーメッセージや自己診断メッセージは表示されるか?される場合は、その内容 ● メッセージの他にエラー番号等は表示されるか? Red Hat K.K. All rights reserved. 57 サポート窓口 L1-L3製品(Red Hatが直接サポートする製品) レ 窓口 ッ ド ハ 窓口 ッ ト    サポート L1-L3製品 L3製品 バックエンドサ ポート L1-L3製品 サポート O E M L3製品 窓口 お 客 様 サポート OEM 各社によるサポートは、障害発生時の HW/SW の一次切り分け、 HW 特有のドライバ提供などの強みがあります OEM各社で、SLAやサポート対象項目等のサポート内容が異なる事があります Red Hat が直接サポートする製品(L1-L3製品)であれば Red Hat サポートセンターが 直接サポートします 58 Red Hat K.K. All rights reserved. upstream first policy Red Hat K.K. All rights reserved. 59 upstream firstポリシー  upstreamとは? ● ●  ソフトウェア開発をおこなうプロジェクトを、RHELなどのディストリビューショ ンでは“upstream”と呼んでいます linux kernelの開発プロジェクト、firefoxの開発プロジェクト、Apache httpdの開 発プロジェクトなど RHELへの修正は基本的に“upstream first”ポリシーで作成されます 1. 問題を発見、原因をつきとめる 2. Red Hatのエンジニアがupstreamへ修正案を提案 3. upstreamで議論→検討→修正実施 4. upstreamでの修正をRHELへバックポート  このようにupstreamを先に修正することで、以下を回避します ● メジャーバージョン変更後に同じ問題が再発すること ● 低品質なバグ修正による追加のトラブル ● upstreamと非常にかけ離れた状態になること Red Hat K.K. All rights reserved. 60