2004年度 情報システム構成論 第8回 分散ファイルシステム 2004年度 情報システム構成論 第8回 分散ファイルシステム 西尾 信彦 nishio@cs.ritsumei.ac.jp 立命館大学 情報理工学部 情報システム学科 ユビキタス環境研究室

ユーザ情報を共有する場合の問題 複数のサーバ上でユーザ環境(個人用設定ファイル等)を同様に構築することが困難 必要なファイルをあちこちに分散したくない 必要なファイルを統一的に扱いたい 分散ファイルシステムを利用する

NFS(Network File System) Unix系OSでほぼ確実に実装されている分散ファイルシステム バイナリ特化のディレクトリサービスと言えなくもない Linux kernel 1.2のころからVersion2が実装されている 歴史が古く、文献が豊富である

各自のHomeとしてNFSを使う 各自のHome(/home以下)をNFSに置くことで可能 複数のホストで同一ユーザディレクトリサービス(NISやLDAP)と同一NFSを利用することによって、複数のホストを同一の環境で利用することができる。 疑問点 なぜ、同一ディレクトリサービスと同一NFSの組で 利用する必要があるのか

Unix系のファイル権限の基礎 Unix系OSでは『ユーザID』によって所有者を見分けている。 『ユーザ名』によってではない つまり 同一ディレクトリサービスと同一ファイルシステムのペアを利用する必要がある

NFSの特徴 古いバージョンでは2GBのファイルまでしか利用することができない 2GB以上のファイルを利用する場合はLinux kernel 2.4.x と glibc version 2.2.x が必要 原則的にファイルアクセスの判断は NISに管理されたユーザIDのみに頼っている NISのドメインでは透明に統一的な扱いになるが ユーザIDを詐称されないようなガードが必要

NFSの問題点 通信経路暗号化が存在しない 接続ホスト認証機構がない 通信途中で回線切断などが起こると操作中のファイルが壊れる可能性がある 通信内容が丸見えである 接続ホスト認証機構がない サーバは接続元アドレスを元に接続の可否を決定する(/etc/exports)ため、接続を許可しているネットワーク内にノートパソコンなどを持ち込まれ，ユーザIDを詐称されるとフルアクセスされてしまう危険性がある また、ユーザ別に接続許可を設置することができない 通信途中で回線切断などが起こると操作中のファイルが壊れる可能性がある ネットワーク的に切断されているときは，キャッシュ以外は一切利用できない

AFS(Andrew File System) Andrew Project (CMU)の成果 NFSにKerberos認証を付加し、個人認証機構と通信暗号化を付加したもの 世界中で共通のルート/../をもつ Multi-institutionalファイルシステム kloginによる期限つきトークンの生成 ファイル(ディレクトリ)操作を詳細に区別 コピー，修正，削除を区別する CMU -> Transarc -> IBM

CFS(Coda File System ) AFS2を基本として、モバイル環境に特化した分散ファイルシステム CMUのSatiyaの研究グループによる成果 ネットワークから一時的にクライアントが切断されても利用可能 以前利用されたファイルなどをキャッシュとして保持し、切断などでアクセスできない場合はキャッシュにアクセスする 復旧時にはマージ処理を行う

Windowsでのファイル共有 Windows独自のファイル共有 Windows以外とのファイル共有 右クリックからフォルダの共有 SMBプロトコル Windows以外とのファイル共有 NFSクライアントを利用する NFSをWindowsで利用する (SFU) ユーザIDマッピングを行う必要がある ほとんどの場合NFSクライアントについている Sambaを利用する Windowsのファイル共有と同等の方法(SMB)でファイルを共有するUNIX上の分散ファイルシステム Unix系で利用可能なSMBインプリメントである Sambaが利用できる

Windowsファイル共有用プロトコル SMB CIFS ファイルが共有可能 プリンタも共有可能 下位のプロトコルとしてNetBIOSを使う MS-DOS時代のLAN Managerから利用されているプロトコル CIFS SMBを拡張し、TCP/IPベースでNetBIOSを利用する必要がない 現在のSambaやWindowsで利用されているプロトコル

Samba SMB/CIFSのUNIX系インプリメンテーション ほとんどすべてのUnix系OSでサポートされている 公式サイト情報より Sun Solaris,Sun OS, HP-UX, IBM AIX, IBM MVS, SGI IRIX, NEC UX/4800,SCO UnixWare, Compaq Tru64 UNIX, Linux, FreeBSD, NetBSD, MachTen など他多数 認証にNIS、LDAPなどを利用することができる

Sambaの問題点 セキュリティ的に脆弱 通信経路の暗号化がない 構造上、Windowsが提供しているのと同程度のセキュリティしか確保できない ユーザ名・パスワードなどの送信時に暗号化されないため、平文で流れてしまう。

WebDAV （Web-based Distributed Authoring and Versioning) HTTP(80 port)のみ公開することで利用できるため、ファイアウォール等の設定が安易 通信経路の暗号化などは、既存のWeb技術を利用することによって可能(SSL等) HTTPを利用するため、OSやサーバ実体に依存しない

P2P(Peer to Peer) 最近(いろいろと)騒がれている分散ファイルサービス 二つのノード間で直接ファイルをやり取りする

P2Pの形式比較 中央サーバが接続しているノードとその提供ファイルのリストを管理する方式 (Napstar方式) 利用者管理が安易 不正ファイルなどを監視することが可能 中央サーバが停止すると全体が停止する 不特定多数のノードがバケツリレー方式で提供ファイルリストのマージやファイル送信を行う方式 (Gnutella/FreeNetなど) どこかのノードが停止しても、システム全体が停止することはない(別ノード経由で利用することができる) 不正ファイルなどが提供されていても監視することが困難 利用者管理は困難

分散ファイルシステムまとめ 複数のホストで同一ファイルシステムを扱う 異なるOSや実装上で統一的にファイルを扱う NFS,AFS,CFSなど 異なるOSや実装上で統一的にファイルを扱う NFS,AFS,CFS,Samba,WebDAV,P2P 分散しているファイルを統一的に扱う P2P 将来的には一部が停止しても全体が停止しない堅固な分散ファイルシステムが重要になる

DNS

DNS(Domain Name Service) 分散配置型データベース、ディレクトリサービスの一種 一組織(いわゆるドメイン)単位で自身が管理する範囲の情報を持つサーバを設置・管理する 自身のわからない部分に関しては他のサーバに問い合わせるということを繰り返して、目的の情報にたどり着く 日本の大本はJPNIC JPNICでWhoisを実行すれば（WhoisCGIがある）、登録されているドメイン⇔DNSサーバアドレスが検索できます

DNSの仕組み

DNSの動き

DNSレコード DNSが保持できる主要情報の種類 SOAレコード(Start of Authority) NSレコード PTRレコード ゾーンの情報（更新頻度、シリアル番号など） NSレコード 対象ドメインのDNSサーバ名を指定する PTRレコード IPアドレスに対するホスト名を指定する Aレコード（IPv6の場合AAAAレコード） ホスト名に対応するIPアドレスを指定する CNAMEレコード ホスト名の別名（エイリアス）を指定する （できるだけ使わないほうがよい） MXレコード 対象ドメイン宛メールの受け取りサーバを指定する

DNSの問題点 プロトコル自身にセキュリティ機構が存在しない 返答を偽ることができた場合、正常な通信を別経路に引き込むことができる システム的問題ではないが、非常に重要かつ被害が広範囲に及ぶにもかかわらず、管理が軽視されがち DNSレコード操作には細心の注意を払うべき

DynamicDNS 動的に登録してあるホスト名⇔IPアドレスを変更することができる 無料サービスが多数存在している zive,ddo.jp など 家庭で（ダイアルアップ環境で）サーバを立てるならば重要