SSD 上の名前空間とは何ですか? Linux ではどのように使用されますか?

最新のストレージ、NVMe、Linuxについて本格的に学び始めると、名前空間、パーティション、LVM、コンテナ、Kubernetesなど、さまざまな用語に圧倒されるのは当然です。どれも同じ用語を使っているように見えますが、必ずしも同じ意味ではありません。ここでは、NVMe SSDにおける名前空間とは何か、Linuxではどのように表現されるのか、そして同じ用語が繰り返し使われているため、LinuxカーネルやKubernetesにおける名前空間の役割についても解説し、混乱を解消していきます。

アイデアは、完全な画像を構築することです。 論理名前空間を備えたNVMe SSDLinuxで/dev/nvme0n1デバイスとして公開される方法や、次のようなツールで管理される方法などについて説明します。 nvme-cli最後に、システムレベル（IPC、PID、ネットワークなど）とKubernetesのようなオーケストレーターにおける名前空間の概念について説明します。これらはすべて、実用的で分かりやすいスタイルで、そして何よりも、余計な説明を省かずに解説します。

NVMe SSD 上の名前空間とは何でしょうか?

NVMeテクノロジーにおいて、ネームスペースとは、オペレーティングシステムが独立したブロックデバイスであるかのように認識できる論理ブロックアドレス（LBA）の集合のことです。これはNANDフラッシュメモリの物理的な断片ではなく、SSD内部における論理的な分離です。

製造元がドライブを構成する際、NVMeコントローラはフラッシュメモリを1つ以上のネームスペースに編成します。各ネームスペースはNSID（ネームスペースID）によって識別され、コントローラはこれらのネームスペースをホストシステムに公開する役割を担います。各ネームスペースは独立した宛先としてシステムに提示されるため、1つのSSDがシステムからは複数の異なる「ドライブ」として認識されます。

Linuxでは、各名前空間は、次のタイプのブロックデバイスとして表示されます。 /dev/nvmeXnYここで、Xはコントローラのインデックス（例：0）、Yは名前空間ID（例：1）です。つまり、 /dev/nvme0n1 「NVMeコントローラ0、ネームスペース1」と表示されます。このデバイスは 他のディスクと同じように扱う: 分割可能 formatear、LVM に追加、raw ボリュームとして使用するなど。

重要な点として、ほとんどのドライブでは、デフォルトでは単一のネームスペースが存在し、そのサイズはSSDの使用可能な容量全体をカバーしています。しかし、NVMe規格では、このネームスペースを削除し、それぞれ独自のサイズと特定のプロパティ（特定のLBAフォーマットや特定のセキュリティポリシーなど）を持つ複数のネームスペースを再作成することができます。

NVMe 名前空間のサイズ、容量、使用法

NVMe規格では、 名前空間を特定する これには、各名前空間のサイズ、容量、使用率など、いくつかの重要な指標が含まれています。これらの情報には、次のようなツールでアクセスできます。 nvme-cli コマンドを使用する nvme id-ns そしてまた ハードドライブとSSDを診断するプログラム.

その構造の中で、 NSZE、NCAP、NUSEという3つの重要なフィールドが際立っています。これらをよく理解することは、各ネームスペース内の実際のスペース使用状況や、論理削除操作（TRIMまたはDeallocate）に対するユニットの応答を制御する上で不可欠です。

名前空間サイズ（NSZE）フィールドは、名前空間を構成する論理ブロックの総数を示し、LBA 0からLBA n-1までの番号が付けられます。これは、いわば名前空間の公称サイズであり、ホストが内部的に割り当てられているかどうかに関わらず、使用可能と認識するブロックアドレスの数です。

名前空間容量（NCAP）フィールドは、デバイスが任意の時点で実際に割り当て可能なブロックの最大数を示します。NSZEと同じように見えるかもしれませんが、必ずしも一致するとは限りません。容量は公式の名前空間サイズよりも小さくなる場合があり、これにより高度なスペース管理技術や内部的な過剰プロビジョニングが可能になります。

最後に、名前空間使用率（NUSE）フィールドは、現在割り当てられている論理ブロックの数を示します。フルフォーマット後、NUSEはゼロになります。データが書き込まれるにつれてこの値は増加し、システムがブロック解放コマンド（TRIMまたはDeallocate）を送信したときにのみ再び減少します。このインジケータは、デバイスがスペース解放要求を正しく処理しているかどうかを知る必要があるアプリケーションやシステムにとって非常に役立ちます。

ブロック形式とその他の名前空間機能

サイズと使用状況に加えて、各ネームスペースは、`Identify`コマンドを通じて、サポートする LBA フォーマット、最適なブロック サイズ、エンドツーエンド保護や異なるセキュリティ モードなどの追加機能の有無を記述します。オペレーティングシステムとアプリケーションは、この情報を使用して読み書き操作のサイズを調整し、ハードウェアを最大限に活用します。

1つのSSDは、1つ以上のLBAフォーマット（例：4 KiB、8 KiBなど）に対応できます。一部のモデルでは、すべてのネームスペースが同じフォーマットを共有する必要がありますが、他のモデルでは、各ネームスペースごとに異なるブロックサイズを設定できます。これは、異なるワークロードを組み合わせる場合に特に便利です。例えば、あるネームスペースは小規模なファイルI/Oに最適化され、別のネームスペースは大規模なシーケンシャル読み取りに最適化されている場合などです。

識別構造は、ネームスペースが保護情報（PI）をサポートしているかどうかも示します。保護情報とは、アプリケーションからNANDに至るまでのデータ整合性の検証を可能にする追加のメタデータであり、サイレント破損の可能性を低減します。

同じサブシステム内では、 1つのネームスペースを1つまたは複数のNVMeコントローラに関連付けることができる点に注意が必要です。1つのコントローラにのみ関連付けられている場合はプライベートネームスペース、複数のコントローラに関連付けられている場合は共有ネームスペースと呼ばれます。この柔軟性は、高可用性環境やNVMe-oF（NVMe over Fabrics）ストレージアレイにおいて不可欠です。

名前空間の管理: 作成、削除、関連付け

NVMe仕様には、名前空間を管理するための主要なコマンド群が2つ含まれています。管理コマンドとアタッチメントコマンドです。前者は名前空間の作成、変更、削除を可能にし、後者はサブシステム内の1つまたは複数のコントローラへの名前空間のアタッチまたはデタッチを可能にします。

一般的な流れは次のとおりです。まず、ホストは必要なパラメータ（サイズ、容量、LBAフォーマットなど）を指定して名前空間を作成します。この時点では、名前空間はオペレーティングシステムからブロックデバイスとして認識されません。認識させるには、` attach`コマンドを実行して、特定のコントローラにリンクする必要があります。コントローラのリセットまたは再検出後、システムは最終的にそれを`/dev/nvmeXnY`デバイスとして公開します。

逆のアプローチも可能です。既存のネームスペースをコントローラーから切り離してホストへの公開を停止し、その後完全に削除します。これは通常、ユニット上のネームスペースの配置を再構築する場合、例えば、オーバープロビジョニングの割合を変更したり、異なるテナント間での割り当てを再編成したりする場合などに行われます。

Linuxでは、これに関する参照ツールは nvme-cliこれを使うと、名前空間を一覧表示できます（nvme list）、Identifyで詳細を確認し、新しい名前空間を作成します（nvme create-ns）、それらを添付します（nvme attach-ns）、それらを分離します（nvme detach-ns）をクリックして削除します（nvme delete-nsこれらの操作には通常、管理者権限が必要であり、ユニットのレイアウトに大きな変更が伴うため、慎重に計画する必要があります。さらに、 ファームウェアを最新の状態に保つ.

同一ユニット内で複数の名前空間を扱う場合、隔離された環境（例えば、特定のホスト）にはプライベート名前空間を、より複雑なアーキテクチャ（複数のホストがNVMe-oFサブシステムを介して同じデータに協調的にアクセスする場合）には共有名前空間を使用するのが一般的です。

NVMe SSD を複数の名前空間に分割する理由は何ですか?

SSDの全容量を単一の名前空間で占有させるのが最も簡単な解決策のように思えるかもしれませんが、複数の名前空間を作成する説得力のある理由がいくつかあります。最も一般的な理由としては、論理的なクライアント分離、セキュリティの向上、パフォーマンスと耐久性の微調整などが挙げられます。

クラウドサービスプロバイダーや大規模プラットフォームなど、複数のテナントが利用するシナリオでは、1台の物理SSDで複数のクライアントのデータをホストできます。ネームスペースを使用することで、各テナントはそれぞれ独立した「論理ディスク」を取得できます。これにより、NANDの物理的なパーティショニングを必要とせずに、管理、課金、およびSLA設計が大幅に簡素化されます。

もう一つの一般的な理由は、セキュリティとネームスペースの暗号化です。OPAL互換のNVMeドライブの多くは、LBA範囲に対して暗号化ポリシーを定義できます。単一のネームスペースを使用する場合は、その内部に複数の保護範囲を設定できますが、異なるデータセット用に個別のネームスペースを作成する場合は、各データセットの機密レベルに合わせて、ネームスペースごとに異なるキーと暗号化ルールを適用できます。

同じマシン上で、パフォーマンス要件が大きく異なる環境が存在する場合もあります。例えば、あるネームスペースは重要なデータベース用に確保され、レイテンシを最小限に抑え、耐障害性を向上させるために高いオーバープロビジョニング率が設定されている一方、別のネームスペースはI/O負荷の低いデータ用として使用されるといった具合です。このように分離することで、負荷の高いワークロードが、より繊細なワークロードのパフォーマンスを低下させるのを防ぐことができます。

さらに、ネームスペースを使用すると、モバイル製品、高セキュリティ環境、産業システムにおける組み込みオペレーティングシステムやブートイメージなどの重要なデータに読み取り専用ポリシーを適用できます。NVMeは、ネームスペースを一時的に（次の電源投入まで）、ロックが解除されてドライブが再起動されるまで、あるいはディスクの寿命全体にわたって読み取り専用モードのままにしておくことも可能です。

名前空間によるオーバープロビジョニングと微調整

SSDは常に、システムからは見えない一定量のフラッシュメモリを内部的に確保しており、これはガベージコレクション、ウェアレベリング、不良ブロック管理などの内部タスクのためのオーバープロビジョニング領域として使用されます。しかし、管理者はネームスペースのサイズを調整することで、ホストに割り当てられずに内部予備領域として利用可能なNANDの量を制御できます。

物理フラッシュメモリの総容量よりも大幅に小さい名前空間を作成すると、メモリの大部分がホストに公開されずに残ります。デバイスのオーバープロビジョニングが大きいほど、パフォーマンスの安定性が向上し、書き込みサイクルの耐久性も高まります。これは、書き込み負荷の高いワークロードにとって非常に重要です。

例えば、約7,68TBのSSDが、使用可能な名前空間として定義されているとします。 6,14 TB残りはホストからは見えず、オーバープロビジョニングバッファに追加されます。 nvme-cli 以前の名前空間を削除し、希望のサイズで再作成し、コントローラーに再度接続することで、まさにその効果を実現できます。

このプロセスにおける課題の一つは、ネームスペースのサイズと容量の粒度を適切に調整することです。標準規格では、NSZEとNCAPの両方を、必ずしも論理ブロックサイズと完全に一致させる必要のない単位で処理できます。そのため、値を慎重に選択しないと、アドレス指定できないメモリ領域が少量発生する可能性があります。目標は、この「無駄な」領域を最小限に抑え、ネームスペースを可能な限りバランス良くすることです。

名前空間を作成する際には、デバイスが報告する制限事項を考慮に入れる必要があります。これらの要素に基づいてNSZE値とNCAP値を調整することで、ほぼすべての物理メモリを、ホストがアクセス可能な領域として、またはコントローラが利用できる内部オーバープロビジョニングとして適切に活用できます。

名前空間、Linux パーティション、LVM、ブロックショートカット

Linuxの観点から見ると、各NVMeネームスペースは/dev/nvme0n1のようなベースブロックデバイスとして表示されます。そこから、管理者は、直接I/Oのためにパーティション化せずにそのままにしておく、従来のディスクのようにパーティション化する、またはLVMなどのボリューム管理システムに統合するなど、その使用方法を決定できます。

その名前空間上にパーティションが作成されると、カーネルはそれらを/dev/nvme0n1p1、/dev/nvme0n1p2などとして公開します。接尾辞「p」は、それが名前空間のパーティションであることを示します。これは、/dev/sda1 が /dev/sda のパーティションであるのと同様です。これらのパーティションにはファイルシステムをマウントでき、LVM、ソフトウェアRAIDなどで使用できます。

生のブロックストレージをデータベースや分散ストレージシステムに直接公開することが目的の場合、パーティションのないネームスペースデバイスを使用するか、専用パーティションは用意するもののファイルシステムをインストールしないのが一般的です。このような場合、アプリケーションは通常、論理ブロック単位で直接通信し、独自の内部領域を管理します。

既存の名前空間をデータに影響を与えずに分割することは容易ではないことに注意が必要です。名前空間のレイアウトを変更するには、通常、データのバックアップ、マウント解除、名前空間の削除、そして目的のサイズでの再作成が必要となり、本番環境では綿密な計画が求められます。

権限に関しては、ファイルシステムを持たないブロックデバイスは、他のノードと同様に制御されます。 /devを通して 所有者、グループ、アクセスモードそれに加えて、 ACL、udevルール システム アクセス制御メカニズム (ディスク アクセス用の特別なグループなど) により、名前空間またはそのパーティションの 1 つに対して読み取りと書き込みを実行できるユーザーまたはサービスを決定します。

Linuxカーネルの名前空間: システムリソースの分離

「ネームスペース」という用語は、NVMeの文脈でのみ使用されるものではありません。Linuxカーネルには同名のメカニズムがありますが、これは特定のプロセス向けにシステムリソースを分離するように設計されています。この機能は、Dockerコンテナ、Podman、LXC、そしてFlatpakやBubbleWrapといったサンドボックスなどの技術の基盤となっています。

この場合、名前空間はグローバルなリソース（マウントポイント、ネットワークスタック、PID、ユーザー、ホスト名、クロックなど）を抽象化によってラップし、その名前空間内で動作するプロセスが、そのリソースの独立したインスタンスを参照できるようにします。その名前空間内で行われた変更は、同じ名前空間を共有するプロセスのみに可視となります。

Linuxは現在、cgroup、ipc、mnt（マウント）、net、pid、user、uts、timeなど、いくつかの種類の名前空間をサポートしています。それぞれがシステムの特定の部分を分離します。たとえば、network名前空間を使用すると、コンテナは独自のインターフェースとルーティングテーブルを持つことができ、PID名前空間を使用すると、1から始まる独自のプロセス番号が付与されます。

特定のプロセスがどの名前空間に属しているかを調べるには、 シンボリックリンク /proc/<PID>/ns/各リンクは名前空間識別子を指し、他のプロセスと共有することも (同じ空間にある場合)、異なることもできます (分離された環境の場合)。

Flatpakで使用されているbubblewrap（bwrap）のようなツールは、まさにこれらのメカニズムに依存しています。bwrapは、マウント、PID、ユーザー、ネットワークなどに対して個別の名前空間を持つプロセスを起動することでサンドボックスを作成し、アプリケーションが自身に割り当てられたリソースのみを参照できる限定された環境で実行されるようにします。

unshareとnsenterを使った実践的な実験

特別なものをインストールせずにLinuxの名前空間を試したい場合は、次のようなシステムコマンドを利用できます。 unshare y nsenterこれらは、コンテナやサンドボックス アプリケーションを実行するときに、舞台裏で何が起こっているかを理解するのに非常に役立ちます。

とともに unshare 1 つ以上の分離された名前空間を持つ新しいプロセスを起動できます。たとえば、独自の PID とユーザーのセットを持つシェルなどです。 –user、–pid、–forkなどのオプションを付けて実行すると内部で実行されているプロセスがPID 1を自身のものとして認識し、さらに別のユーザーで実行されるセッションを取得します（たとえば、 誰も）、これはその孤立を強調しています。

このような環境では、 /proc オプションを使用して新規および分離 –マウントプロセスこれを行わないと、これに依存する一部のユーティリティが正しく機能しなくなります。 /proc/<PID>/exe ホスト名前空間に基づいてプロセス情報を表示しようとすると、カーネルがセキュリティ分離を維持するためにそのアクセスをブロックするため、失敗する可能性があります。

また、もし unshare アメリカではない -フォーク同じプロセス内でコマンドを実行し、マウントできないなどの奇妙なエラーを引き起こす可能性があります。 /proc プロセスが新しい名前空間内で PID 1 の正しい役割を引き受けないため、適切に実行されなかったり、メモリ割り当てに失敗したりします。

さらに、 nsenter これは逆のことを行います。つまり、既存のプロセスの名前空間に「入る」ことを可能にします。これは、コンテナやFlatpakアプリケーションがホストからどのように世界を見ているかを調べるために一般的に行われることです。内部に入ると、まるでコンテナの「内部」にいるかのように、ネットワークスタック、マウントポイント、内部プロセステーブルなどを検査できます。

名前空間とコンテナ: Flatpak から Podman と Docker まで

カーネルの名前空間を理解すれば、コンテナが魔法ではなく、リソースを分離するための名前空間、消費量を制限するためのcgroup、権限を制御するためのケーパビリティ、アプリケーションをパッケージ化するための階層型ファイルシステムといった、いくつかの基本要素の組み合わせであることが容易に理解できます。

Flatpakは、Bubblewrapを使用してデスクトップアプリケーション用の隔離された環境を作成します。各アプリケーションは、アクセスできるパス、プロセスの可視性、ネットワークアクセスなどが制限された一連の名前空間内で実行されます。プロセスレベルでは、PID、マウントポイント、そして多くの場合、ユーザーもホストシステムのものとは異なることが明らかです。

同様に、 LXC、Docker、Podman これらは、汎用コンテナを構築するために異なる名前空間で構成されています。例えば、ルートレスコンテナは、内部IDをホスト上の非特権IDにマッピングするためにユーザー名前空間を使用し、専用の仮想インターフェースを持つためにネットワーク名前空間を使用します。ホスト上のコンテナプロセスIDを分析し、次のように入力します。 nsenterこの分離は直接検証することができます。

より簡単に「ルートレス」名前空間を作成したい場合は、rootlesskitのようなツールを使用できます。これらのツールは、権限を持たないユーザーがルートに直接アクセスすることなく隔離された環境を作成できるように、必要なすべての設定を支援します。これは、現代のマルチユーザー環境でますます求められている機能です。

Kubernetes の名前空間: 論理仮想クラスタ

Kubernetesでは「名前空間」という用語が再び登場しますが、ここでは単一のクラスタ内のリソースを分割するための論理的なメカニズムを指します。これはNVMeブロックアドレスやカーネルレベルの分離とは何の関係もありませんが、概念的には分離と整理のためにも使用されます。

Kubernetesにおいて、ネームスペースは物理クラスタ内の仮想クラスタのようなものです。リソース（ポッド、サービス、デプロイメントなど）をグループ化することで、複数の物理クラスタをセットアップすることなく、チーム、プロジェクト、または環境（開発、テスト、本番）ごとに管理および分離することができます。

これらの名前空間により、同じ名前のリソースを異なるコンテキストに存在させることができます。たとえば、開発用名前空間に「my-service」という名前のサービスがあり、本番環境にも同じ名前のサービスがあっても、競合は発生しません。なぜなら、一意性は各名前空間内でのみ保証されるからです。

さらに、Kubernetesの名前空間はRBAC（ロールベースアクセス制御）と統合されています。特定の名前空間内でリソースを作成、変更、または読み取ることができるユーザーまたはサービスアカウントを制限する権限を定義することが可能で、インフラストラクチャを共有する異なるチームや組織間での安全な委任を大幅に容易にします。

もう一つの重要な要素は、リソース割り当てです。Kubernetesでは、名前空間ごとに、ワークロードが消費できるCPU、メモリ、オブジェクト（Podなど）、その他のリソースの量を制限できます。これにより、単一のプロジェクトがクラスタ全体を消費してしまうことを防ぎ、より予測可能で公平なリソース利用を促進します。

Kubernetesにおける名前空間の実践的な操作

新しくインストールされたクラスターでは、Kubernetesは通常、default、kube-system、kube-publicという複数のデフォルト名前空間を作成します。最初の名前空間は名前空間を指定しないリソースに使用され、2番目は内部システムコンポーネントに使用されます。3番目は認証されていないユーザーでもアクセス可能で、クラスターレベルで公開読み取りが必要な特定の要素用に予約されています。

利用可能な名前空間を確認するには、 kubectl get namespaces またはその略語を入力します。そこから管理者は 名前空間の作成と削除 必要に応じて、通常はプロジェクトベースまたは環境ベースの組織戦略に従って（たとえば、 devの, ステージング, 突く).

コマンドが起動されると kubectlターゲット名前空間は、オプションを使用して一時的に指定できます。 –名前空間または、すべての操作が特定の名前空間を指すようにするデフォルトのコンテキストを構成することもできます。これにより、エラーが削減され、各コマンドでオプションを入力する必要がなくなります。

DNSに関して、Kubernetesは`<service-name>.<namespace>.svc.cluster.local`のような完全修飾ドメイン名（FQDN）を使用してサービスを登録します。同じ名前空間内であれば、サービス名を使用するだけで十分であり、残りの処理はDNS解決によって行われます。ただし、ある名前空間内のPodから別の名前空間内のサービスにアクセスする場合は、FQDN、または少なくともサービス名と名前空間を含む部分的な名前を使用する必要があります。

Kubernetesのオブジェクトはすべて名前空間内に存在するわけではありません。名前空間自体、ノード、および永続ボリュームはクラスタレベルのリソースであり、名前空間内にカプセル化されていません。これは、どのリソースが論理的にセグメント化され、どのリソースがグローバルとみなされるかを理解するために重要です。

一般的に、名前空間の使用は、クラスターに既に相当数のユーザーやアプリケーションが存在する場合、またはマシン間の明確な分離が必要な場合に推奨されます。アプリケーションのバージョンなど、それほど重要でない差異については、名前空間の数を不必要に増やすよりも、同じ名前空間内でラベルを使用する方が通常は良いでしょう。

ブロックアドレスを分割するためのNVMe SSD名前空間、プロセスリソースを分離するためのカーネル名前空間、クラスタリソースを論理的に整理するためのKubernetes名前空間など、これらの要素をすべて組み合わせると、関連する概念に対して同じ言葉が再利用されていることがわかります。それは、共有空間内にそれぞれ独自のビジョンとルールを持つ独立したドメインを作成するということです。どのレイヤーにいるのかを常に理解することが、整理されたシステムと維持管理不可能なシステムとの違いを生み出すのです。