Data Domain:DDFS (Data Domain ファイルシステム) のクリーンアップ/ガベージコレクション (GC) フェーズの概要
Summary: この記事では、Data Domain のクリーニング/ガベージコレクション中のフェーズの概要を説明し、Data Domain オペレーティングシステムのさまざまなリリースで使用されているさまざまなクリーンアルゴリズムの違いについて説明します。
This article applies to
This article does not apply to
This article is not tied to any specific product.
Not all product versions are identified in this article.
Symptoms
DDFS (Data Domain ファイルシステム) は、多くの一般的なファイルシステムの実装とは異なり、ファイルが使用するファイルシステムの領域からファイルが削除されると、すぐに再使用できなくなることがあります。これは、Data Domain Restorer (DDR) では、削除されたファイルによって参照されたデータが他のファイルによって重複排除されているかどうかがすぐにはわからないためです。このため、そのデータを削除することが安全であるかどうかを確認する必要があります。
クリーニング (ガベージコレクション/GC とも呼ばれる) は、DDR を行うプロセスです。
この記事では、clean/GC について詳細に説明します。
クリーニング (ガベージコレクション/GC とも呼ばれる) は、DDR を行うプロセスです。
- 不要なディスク上のデータ (ファイルまたはスナップショットなどのオブジェクトによって参照されなくなったもの) を決定します。
- 不要なデータを物理的に削除して、再利用可能な基盤となるディスク領域を確保します (つまり、新しいデータの取り込み)。
- 長時間実行中
- Cpu の負荷が高い
この記事では、clean/GC について詳細に説明します。
- クリーニングが一般的に実行されるフェーズ
- DDOS のさまざまなバージョンで使用されるさまざまなクリーンアルゴリズム
Cause
なし
Resolution
クリーンアップ/GC が実行されるたびに、2つの主な目的があります。最初は、DDR で不要なデータを見つける必要があります。これは、次のようになります。
Clean/GC がコピーフェーズに達するまで、システム上の領域は物理的に解放されないことに注意してください。その結果、クリーンアップが開始されるまでにかなりの遅延が発生している可能性があります (列挙プロセスが最初に完了する必要があるため)。このため、clean/GC が開始される前に、システムが100% フルになることはできません。
列挙フェーズは CPU utilisation (一般的には CPU がバインドされている) という点でコストが高くなる傾向がありますが、コピーフェーズは CPU と i/o の両方においてコストが高くなります (一般的には CPU と i/o がバインドされています)。ただし、次のように指定することもできます。
DDOS 5.4 (以前の)-フルクリーンアルゴリズム: 6個または10個のフェーズ (前述のように) を実行します。
同様に、DDOS 5.x から 6.0 (またはそれ以降) にアップグレードした場合は、物理から完璧な物理クリーンアルゴリズムに変更されます。ただし、正確な物理クリーンアルゴリズムでは、インデックスを使用する前に、インデックスを「index 2.0」形式にする必要があることに注意してください。以下の点に注意してください。
前述したように、clean/GC アルゴリズムが使用されているかどうかにかかわらず、clean はさまざまなフェーズを必要とする場合があります。たとえば、完全なクリーンアルゴリズムでは6または10のフェーズが必要になる場合があります。理由は次のとおりです。
が発生します。システムが物理クリーンアルゴリズムから真の物理クリーンアルゴリズムに切り換えられたことを直接判別できる情報はありません。
クリーンアルゴリズムに関係なく、コピーフェーズ (dead データがシステムから物理的に削除される場合) は、すべてのリリースで同様の方法で機能します。コピーフェーズのパフォーマンスは、次のようになります。
例 1:
例1で説明されているコピーを実行するには、i/o の量が大幅に高く、CPU が使用されていることを明らかにします。この例では、ディスクの 45 Mb の物理スペースを解放するにはかなり長い時間がかかります。
一般的に、ユーザーは、システムに書き込まれるデータの使用事例やタイプに依存するため、DDR のディスク上の dead データの「断片化」を制御することはありません。ただし、clean/GC は、コピーフェーズ中に発生した dead データの「フラグメント化」を判断するのに役立つ統計を保持します (したがって、ユーザーは、このフラグメント化が長時間実行されている可能性があるコピーフェーズを説明できるかどうかを判断することができます)。クリーン/GC の最新フェーズからの統計情報は、自動サポートで収集されます。例えば、次の例は、dead データが隣接しているコピーフェーズを示しています (つまり、コピーに対して選択されたコンテナの大部分は、ほとんどの dead データを保持しています)。コピーされる
ライブデータの割合: 3.6% 4.3%
次の図は、dead データがフラグメント化されているコピーフェーズを示しています (つまり、コピーに対して選択されたコンテナの大部分は、ほとんどのライブデータを保持しています)。コピーされる
ライブデータの割合: 70.9% 71.5%
前述の clean/GC は、コピーフェーズのスループットを減らすために、DDR の領域を物理的に解放するために、2つ目のシナリオで比較的かなり多くの作業を実行する必要があります。
コピーフェーズのスループットは、以下のように悪影響を受ける可能性もあります。
- Clean/GC は、システム上に現在存在しているファイル、スナップショット、レプリケーションログなどのオブジェクトを探す DDFS ファイルシステムの内容を列挙します。
- 次に、これらのオブジェクトによってアクティブに参照されるディスク上のすべての物理データを特定します。
- アクティブに参照されるデータは「live」と呼ばれ、DDR から削除することはできません。そうしないと、このデータを参照するオブジェクトが破損します (これは、従属するデータがディスク上に存在しなくなったため、読み取れなくなる可能性があります)。
- どのオブジェクトによってもアクティブに参照されていないデータは「dead」であり、不要なデータであるため、このデータをシステムから安全に取り外すことができます。
- DDR 上のすべてのデータは、コンテナと呼ばれる 4.5 Mb のオブジェクトにパックされています。
- 列挙のクリーンアップと GC を通じて、どの 4.5 Mb のコンテナーが dead データを保持しているか、それぞれの dead データの量を確認できます。
- デフォルトでは、clean/GC は > 8% の dead データを保持している「処理中」を保持する 4.5 Mb のコンテナを選択します。
- 処理用に選択されたコンテナは、適切な dead データを保持していることを確認するために再度チェックされます。
- Live データはこれらのコンテナから抽出され、ファイルシステムの最後に新しい 4.5 Mb のコンテナに書き込まれます。
- これが完了すると、選択されたコンテナ (それらの中の dead データを含む) はディスク領域を物理的に解放します。
- DDR で使用されている DDOS のバージョン (これにより、デフォルトでは、DDOS のバージョンによりクリーンアルゴリズムが使用されます)
- システムの構成/内容
- 列挙前-DDFS ファイルシステムの内容を列挙します。
- マージ前: インデックス情報の最新のコピーがディスクにフラッシュされるように、DDFS インデックスマージを実行します。
- 事前フィルター-DDFS ファイルシステム内に重複するデータがあるかどうかを判断します。この場合、次のようになります。
- 事前選択-クリーニングによって、どの 4.5 Mb のコンテナーを「処理中」にするかを決定します。
- [Copy]: 選択したコンテナから live データを物理的に抽出し、それを新しいコンテナに書き込んでから、選択したコンテナを削除します。
- Summary: 再構築サマリベクトル (新しいデータの取得中に最適化として使用)
Clean/GC がコピーフェーズに達するまで、システム上の領域は物理的に解放されないことに注意してください。その結果、クリーンアップが開始されるまでにかなりの遅延が発生している可能性があります (列挙プロセスが最初に完了する必要があるため)。このため、clean/GC が開始される前に、システムが100% フルになることはできません。
列挙フェーズは CPU utilisation (一般的には CPU がバインドされている) という点でコストが高くなる傾向がありますが、コピーフェーズは CPU と i/o の両方においてコストが高くなります (一般的には CPU と i/o がバインドされています)。ただし、次のように指定することもできます。
- 列挙フェーズの合計長は、列挙する必要のある DDR のデータ量によって異なります。
- コピーフェーズの合計長は、削除する必要のある DDR 上の dead データの量と、そのデータがディスク上にあることを示す「断片化」の方法によって異なります (以降で説明)
DDOS 5.4 (以前の)-フルクリーンアルゴリズム: 6個または10個のフェーズ (前述のように) を実行します。
- DDFS ファイルシステムの内容は、トップダウンで列挙されます (つまり、ファイル中心)。
- DDFS は、DDR 上に存在するすべてのファイルを検出し、そのファイルによって参照されるデータを確認するために、各ファイルを順番にスキャンします。
- これにより、clean/GC は、ディスク上のどのデータを「有効」にするかを決定します。
- DDFS の内容が列挙されます (つまり、個別のファイルをスキャンしなくなります)。
- DDFS は、ディスク上の物理データを参照するファイルシステムメタデータを検出し、そのメタデータをスキャンして、どのデータを参照しているかを判別します。
- これにより、clean/GC は、ディスク上のどのデータを「有効」にするかを決定します。
- これは、「分析」フェーズの追加によって実現されます (したがって、フルクリーンアップアルゴリズムのフェーズ数が増加します)。
- ただし、ほとんどの場合、物理クリーニングの総期間は、同一システムの完全クリーンアップよりも短くなることが予想されます (個々のフェーズで構成されています)。
- これは単なる物理クリーンアルゴリズムへの最適化で、次に説明します。
- 小さなファイルの数が多い (1 つのファイルの列挙を次のファイルに移動したときに、コストがかかる/低速になる)
- 高重複排除率 (複数のファイルが同じ物理データを参照し、同じデータを複数回列挙するため)
同様に、DDOS 5.x から 6.0 (またはそれ以降) にアップグレードした場合は、物理から完璧な物理クリーンアルゴリズムに変更されます。ただし、正確な物理クリーンアルゴリズムでは、インデックスを使用する前に、インデックスを「index 2.0」形式にする必要があることに注意してください。以下の点に注意してください。
- 「Index 2.0」形式は DDOS 5.5 を使用して導入されました (つまり、5.5 以降に作成されたすべてのファイルシステムは、すでにインデックス2.0 を使用しています)。
- 5.4 またはそれ以前のバージョンで作成されたファイルシステムでは、最初はインデックス1.0 形式でインデックスが作成されています。DDOS 5.5 (またはそれ以降) にアップグレードした後、インデックスは、clean が実行されるたびに変換さ2.0 れます。ただし、最大で2年間 (フル実行の場合は週単位) に変換され、インデックスが2.0 フォーマットに完全に変換されることになります。
前述したように、clean/GC アルゴリズムが使用されているかどうかにかかわらず、clean はさまざまなフェーズを必要とする場合があります。たとえば、完全なクリーンアルゴリズムでは6または10のフェーズが必要になる場合があります。理由は次のとおりです。
- DDFS が開始されると、クリーンアップ/GC によって使用される固定量のメモリを予約します。
- このメモリクリーンアップ/GC 内では、列挙の結果を説明するためにデータ構造を作成します (つまり、live と dead データがディスク上に存在することを説明します)。
- DDR に比較的少量のデータが含まれている場合は、DDFS ファイルシステムの内容全体を、このメモリ領域で説明することができます。
- ただし、多くのシステムでは、これは不可能で、DDFS ファイルシステム全体の内容が列挙される前にメモリの領域が使い果たされることになります。
- したがって、これらのシステムは「サンプリング」を実行します。これにより、必要なクリーンアップフェーズの数が増加します。
- ファイルシステム全体で列挙のサンプリングパスを実行します。この列挙は「完了」ではないことに注意してください (つまり、ファイルシステムの各部分についての完全な情報を記録せず、ファイルシステムの各部分の情報を概算します)。
- このサンプリング情報を使用して、DDFS ファイルシステムのどの部分に対して clean/GC を実行するのかを判断します (つまり、ファイルシステムのどの部分が、クリーニングされた場合に、解放されるスペースの最適な結果を得ることができます)。
- ファイルシステムの選択された部分に対して、2番目の完全な列挙を実行します。ここでは、コンテンツを GC 用に予約済みのメモリ内に完全に記述できるようになりました。
- クリーンアップ/GC によって実行される必要のあるフェーズの数の増加
- クリーンアップ/GC の総継続時間の増加
が発生します。システムが物理クリーンアルゴリズムから真の物理クリーンアルゴリズムに切り換えられたことを直接判別できる情報はありません。
- システムが DDOS 5.5-5.7 で物理クリーンアップを実行していたときに、クリーニング中に12個のフェーズを実行しました
- システムが DDOS 6.0 (またはそれ以降) にアップグレードしている場合、クリーニング中は7つのフェーズのみを実行します。
クリーンアルゴリズムに関係なく、コピーフェーズ (dead データがシステムから物理的に削除される場合) は、すべてのリリースで同様の方法で機能します。コピーフェーズのパフォーマンスは、次のようになります。
- 削除する必要がある「dead」データの量
- この dead データの「フラグメンテーション」 (つまり、ディスク間でどのように分散しているか)
例 1:
- コピー用に10個のコンテナが選択されている (合計データ量)
- これらのコンテナーが live データを保持していない場合 (つまり、保存されているデータは完全には未参照/dead)
- 結果のコピーでは、これらのコンテナを削除済みとしてマークし、ディスク上の 45 Mb の物理スペースを解放します。
- 100コンテナがコピー対象として選択されている (450Mb 合計データ)
- これらの各コンテナは、90% のライブデータ/10% の dead データを保持します。
- これらのコンテナーを処理するには、次の操作を行う必要があります。
全100コンテナからの90% のライブデータの読み取り (405Mb のデータ)
この405Mb データをファイルシステムの最後に保持する一連の新しいコンテナを作成します。
この405Mb のデータをこれらのコンテナに書き込み、それに応じてインデックスなどの更新構造体を更新します。
100の選択したコンテナを削除済みとしてマークすることにより、ディスク上の45Mb の物理スペースを解放します。
例1で説明されているコピーを実行するには、i/o の量が大幅に高く、CPU が使用されていることを明らかにします。この例では、ディスクの 45 Mb の物理スペースを解放するにはかなり長い時間がかかります。
一般的に、ユーザーは、システムに書き込まれるデータの使用事例やタイプに依存するため、DDR のディスク上の dead データの「断片化」を制御することはありません。ただし、clean/GC は、コピーフェーズ中に発生した dead データの「フラグメント化」を判断するのに役立つ統計を保持します (したがって、ユーザーは、このフラグメント化が長時間実行されている可能性があるコピーフェーズを説明できるかどうかを判断することができます)。クリーン/GC の最新フェーズからの統計情報は、自動サポートで収集されます。例えば、次の例は、dead データが隣接しているコピーフェーズを示しています (つまり、コピーに対して選択されたコンテナの大部分は、ほとんどの dead データを保持しています)。コピーされる
ライブデータの割合: 3.6% 4.3%
次の図は、dead データがフラグメント化されているコピーフェーズを示しています (つまり、コピーに対して選択されたコンテナの大部分は、ほとんどのライブデータを保持しています)。コピーされる
ライブデータの割合: 70.9% 71.5%
前述の clean/GC は、コピーフェーズのスループットを減らすために、DDR の領域を物理的に解放するために、2つ目のシナリオで比較的かなり多くの作業を実行する必要があります。
コピーフェーズのスループットは、以下のように悪影響を受ける可能性もあります。
- 暗号化の使用: データを復号化してコピー中に再暗号化する必要があります。これにより、必要な CPU の量が大幅に増加します。
- 低帯域幅の最適化の使用: コンテナでは、コピー中に「スケッチ」情報を生成する必要があります。これにより、必要な CPU 容量が大幅に増加します。
Additional Information
クリーンアップのスケジュールとスロットルのチェック/変更の詳細については、次のナレッジベース記事を参照してください。 https://support.emc.com/kb/306100
注:
「100」のクリーニングスロットルを使用している DDR (つまり、最高または最も積極的なスロットル設定) は、クリーンアップの実行中にかなりの CPU と i/o を使用し、DDR が他のワークロードの対象である場合でも、リソースを解放しません (このシナリオでは、クリーンアップを実行すると、取得/リストア/レプリケーション操作のパフォーマンス
例:
この情報は、次のように、Data Domain の DDCLI (コマンドラインシェル) からも表示できます。
DDCLIにログインします。
# system show serialno
-Display GC statistics:
SE@dd4200 # # filesys show detailed-stats 70
GC stats for Physical clean on Active Success 1 中止された最新の成功した
gc コンテナ範囲: 198 ~ 562458
GC フェーズ: マージ前の時間: 177の平均: 177 seg/秒: 0続き/s: 857
GC フェーズ: 事前分析時間: 187の平均: 187 seg/秒: 0続き/s: 811
GC フェーズ: 事前列挙時間: 573の平均: 573 seg/秒: 1086296継続/秒: 264
GC フェーズ: 事前フィルター時間: 181の平均: 181 seg/秒: 1728325継続/秒: 838
GC フェーズ: 事前選択時刻: 77の平均: 77 seg/秒: 3500864継続/秒: 1970
GC フェーズ: コピー時刻: 54の平均: 54 seg/秒: 0続き/s: 2809
GC フェーズ: サマリー時間: 1平均: 1 seg/秒: 0続き/s: 151726
...
注:
- 通常の状況では、クリーニングは週に1回実行するようにスケジュール設定する必要があります。これよりも頻繁にクリーンアップを実行すると、ディスク上のデータが過度に断片化することになります (つまり、不良領域の局所性が低下する可能性があります)。その結果、読み取り/レプリケーション/データ移動のパフォーマンスが低下する
- クリーニングスロットルは、クリーンアップによって消費されている CPU と i/o 帯域幅の合計には影響しません。そのため、システム上の他のワークロードに対する機微の消去方法を制御します。例:
クリーンスロットルが「1」である DDR (つまり、最小または最小のスロットル設定) でも、クリーンアップの実行中にかなりの CPU と i/o が使用されます。ただし、DDR が他のワークロードを実行するとすぐにリソースのバックアップを直ちに解放する必要があります。
「100」のクリーニングスロットルを使用している DDR (つまり、最高または最も積極的なスロットル設定) は、クリーンアップの実行中にかなりの CPU と i/o を使用し、DDR が他のワークロードの対象である場合でも、リソースを解放しません (このシナリオでは、クリーンアップを実行すると、取得/リストア/レプリケーション操作のパフォーマンス
- デフォルトでは、クリーニングスロットルは50に設定されています。これは、DDR によって、異なるスロットル設定で実行中の clean をテストするユーザーの責任です。この場合、では、通常のワークロードを使用して、次のスロットル設定を決定します。
可能な限り最短の時間で実行してください。
他のワークロードのパフォーマンスを過度に低下させることなく、クリーンアップを実行します。
- 長期間実行されると、必ずしも次のような問題ではないことに注意してください。
クリーニングは、スケジュールされた開始時刻の間に完全に完了することができます (つまり、[clean] は、火曜日の6am で開始するようにスケジュール設定されている場合は、次の火曜日を6am する前に完了してください)
システムに十分な空き容量があり、そのコピーフェーズにクリーンに達してから、スペースの再利用が開始されます。
クリーンアップを実行しても、他のワークロードのパフォーマンスが過度に低下することはありません。
- Extended retention 機能を使用しているシステムは、以下のように構成する必要があります。
アクティブ-> アーカイブ階層からのデータ移動は、定期的に実行するようにスケジュール設定されています (つまり、1週間に1回)。
アクティブ階層のクリーニングは、データ移動の完了時に実行するようにスケジュール設定されています。
アクティブ階層のクリーンには、独自のスケジュールまたは独立したスケジュールはありません (これにより、過剰なクリーニングが実行される可能性があります)。
- 自動サポートおよび details には、最新のクリーン操作からの完全な情報が含まれています。
クリーンアップ中に実行するフェーズの概要
クリーンアップの各フェーズの継続時間とスループット
クリーンアップの各フェーズの詳細な統計情報
例:
アクティブな39正常終了時の物理クリーニングの GC 統計が中止されました
。最後に成功した gc コンテナ範囲: 15925661 ~ 62813670
GC フェーズ: マージ前の時間: 133の平均: 154 seg/秒: 0続き/s: 0
GC フェーズ: 事前分析時間: 1331の平均: 1768 seg/秒: 0続き/s: 0
GC フェーズ: 事前列挙時間: 34410の平均: 31832 seg/秒: 1471833継続/秒: 0
GC フェーズ: 事前フィルター時間: 2051の平均: 1805 seg/秒: 1988827継続/秒: 0
GC フェーズ: 事前選択時刻: 2770の平均: 2479 seg/秒: 1472593継続/秒: 2675
GC フェーズ: マージ時間: 111の平均: 69 seg/秒: 0続き/s: 0
GC フェーズ: 解析時刻: 1350の平均: 900 seg/秒: 0続き/s: 0
GC フェーズ: 候補時間: 1478の平均: 739 seg/秒: 6833465継続/秒: 2156
GC フェーズ: 列挙時間: 37253の平均: 20074 seg/秒: 5490502継続/秒: 0
GC フェーズ: フィルタ時間: 1667の平均: 910 seg/秒: 9787652継続/秒: 0
GC フェーズ: コピー時刻: 52164の平均: 49496 seg/秒: 0続き/s: 61
GC フェーズ: サマリー時間: 2840の平均: 2427 seg/秒: 5552869継続/秒: 2501
GC 分析フェーズの詳細:
インデックス内の最近のセグメントの累積数: 16316022459 572186212855
固有セグメント数の反復: 494653358 319255282440
固有の Lp セグメント数: 494653866 17879171482
遅延バッファ再割り当て数: 0 0
インデックスのフルアップグレード: 1 16
Lps のみをスキャンします。 1 39
最大 Lp セグメント数がサポートされています。 18105971430 706132885747
...
。最後に成功した gc コンテナ範囲: 15925661 ~ 62813670
GC フェーズ: マージ前の時間: 133の平均: 154 seg/秒: 0続き/s: 0
GC フェーズ: 事前分析時間: 1331の平均: 1768 seg/秒: 0続き/s: 0
GC フェーズ: 事前列挙時間: 34410の平均: 31832 seg/秒: 1471833継続/秒: 0
GC フェーズ: 事前フィルター時間: 2051の平均: 1805 seg/秒: 1988827継続/秒: 0
GC フェーズ: 事前選択時刻: 2770の平均: 2479 seg/秒: 1472593継続/秒: 2675
GC フェーズ: マージ時間: 111の平均: 69 seg/秒: 0続き/s: 0
GC フェーズ: 解析時刻: 1350の平均: 900 seg/秒: 0続き/s: 0
GC フェーズ: 候補時間: 1478の平均: 739 seg/秒: 6833465継続/秒: 2156
GC フェーズ: 列挙時間: 37253の平均: 20074 seg/秒: 5490502継続/秒: 0
GC フェーズ: フィルタ時間: 1667の平均: 910 seg/秒: 9787652継続/秒: 0
GC フェーズ: コピー時刻: 52164の平均: 49496 seg/秒: 0続き/s: 61
GC フェーズ: サマリー時間: 2840の平均: 2427 seg/秒: 5552869継続/秒: 2501
GC 分析フェーズの詳細:
インデックス内の最近のセグメントの累積数: 16316022459 572186212855
固有セグメント数の反復: 494653358 319255282440
固有の Lp セグメント数: 494653866 17879171482
遅延バッファ再割り当て数: 0 0
インデックスのフルアップグレード: 1 16
Lps のみをスキャンします。 1 39
最大 Lp セグメント数がサポートされています。 18105971430 706132885747
...
この情報は、次のように、Data Domain の DDCLI (コマンドラインシェル) からも表示できます。
DDCLIにログインします。
: 「Se」モードにドロップします。
# system show serialno
[表示されるシステムシリアル番号]
# priv set se
(一部のシステムでは、この段階でセキュリティロールを持つユーザーの詳細の入力を求められる場合があります)。
[パスワードプロンプト-上のシリアル番号を入力してください]
-Display GC statistics:
SE@dd4200 # # filesys show detailed-stats 70
GC stats for Physical clean on Active Success 1 中止された最新の成功した
gc コンテナ範囲: 198 ~ 562458
GC フェーズ: マージ前の時間: 177の平均: 177 seg/秒: 0続き/s: 857
GC フェーズ: 事前分析時間: 187の平均: 187 seg/秒: 0続き/s: 811
GC フェーズ: 事前列挙時間: 573の平均: 573 seg/秒: 1086296継続/秒: 264
GC フェーズ: 事前フィルター時間: 181の平均: 181 seg/秒: 1728325継続/秒: 838
GC フェーズ: 事前選択時刻: 77の平均: 77 seg/秒: 3500864継続/秒: 1970
GC フェーズ: コピー時刻: 54の平均: 54 seg/秒: 0続き/s: 2809
GC フェーズ: サマリー時間: 1平均: 1 seg/秒: 0続き/s: 151726
...
Affected Products
Data DomainProducts
Data DomainArticle Properties
Article Number: 000017462
Article Type: Solution
Last Modified: 11 Dec 2023
Version: 4
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.