|
[35203]
|
193.220.82.3 |
| tacco さん |
Posted in 2002-10-16 04:42:30 |
| 1. Reply: ファイルサーバ |
c4350.isid.co.jp |
| よねよね さん |
Posted in 2002-10-16 10:31:17 |
| 自分的には、ボトルネックになる順番は、1がネットワーク、2にDISK I/Oだと思います。 一般的な100BASE-TXのネットワークは12.5MB/secですが、これではせいぜい二昔前のHDDと同程度です。(^^; そして、ディスクやネットワークI/Oに、メモリやCPUはあまり必要ないと思います。 とは言え、アンチ・ウィルスソフトが走っていたり、ディスクがRAID 5構成だったり、ネットワークにダムHUBを使っていたりで色々と変わってきますので、ローカルHDへの読み書き速度やRAMディスクへの読み書きを行ってベンチマークを取りつつ、さらにCPU負荷やメモリの消費量をモニタリングするしか、正確なところは分からないと思います。 |
|
| 2. Reply: ファイルサーバ |
aa2002050606003.userreverse.dion.ne.jp |
| Lunx さん |
Posted in 2002-10-16 12:39:34 |
| 実体験ですが、100Baseのネットワークでmp3のファイルをファイルサーバー越しで再生 しているとき、転送が足らないのか多少音が変わりました。 ビットレートや再生ソフトにもよるでしょうが、動画の場合はさらに変化が大きいのでは．． |
|
| 3. Reply: ファイルサーバ |
yahoobb218181116028.bbtec.net |
| WELLNOW さん |
Posted in 2002-10-16 17:13:39 |
| LANでの処理が速くなるかどうかは、送信側・受信側のCPU占有率にも寄ると思います。 うちでのSCSI SYSTEMだと、2MByte/Sを必要とする極悪(笑)AVIでも、滞りなく再生できましたし。 AMD K6-III+600Mhz MEM:EDO ECC 384MByte のような今となっては、少々旧世代のでも、 SCSI IF:SC-U2PS・ASC-29160 HDD:ST318452LW LAN IF :Intel 82557 Chip 等を加えれば、問題有りませんでした。 AdaptecのIFは、CPU占有率が低めで、システム高負荷時の安定した転送を見せてくれます。 それで、同じくCPU占有率やパケットロスを下げる方向で考えていけば、パケットロスの少ないIntelや3Com製Chipを搭載したLAN IFをはじめ、Swiching HUBもカットスルー方式ではなく、ストア&フォワード方式を採用している物、カテゴリー５or Hiカテゴリー５ケーブルを使うべきです。 まあ、目的次第でここまでタイトに考えなくても良いとは思いますが、既存のネットワークサーバがどうなっているのかを考えて頂ければ、上記のようになります。 |
|
| 4. Reply: ファイルサーバ |
229.net219096028.t-com.ne.jp |
| Tonbo さん |
Posted in 2002-10-16 21:00:08 |
| 最近、ファイルサーバを作ろうと考えて、あれこれ調べました。一般の技術解説では、 ファイルサーバはCPUに対しての要求が低い、あるいはあまり影響しないとされています。 しかし、あるインテル互換CPU（約Celeron500MHzに相当とされている）を使用している ミニマザーボードについて、100/10MB規格のLANボードにもかかわらず、いらいらするほ ど遅いと報告されています。このマザーボードではwin2000が問題なく使われているそうで す。また、最近出たある有名メーカーのネットワークHDD(120MGB)（直接HDDをLANに繋 ぐ）ものでも、スペック表のデータを見ると、とても遅くて、？十GBのデータ関係にと ても使えづらい感じと思われます。せいぜい差分バックアップぐらいでしょう。 いろいろとまとめて見ると、ファイルサーバでもCPUに非常に影響されているようです。 |
|
| 5. Reply: ファイルサーバ |
ppp211016118214.adsl.flets.nmt.ne.jp |
| いしかわ さん |
Posted in 2002-10-17 00:21:50 |
| ブロードバンドな環境(とくに光)では、CPUパワーがないと回線速度が生かせないのと同じように、ファイルサーバにもある程度のCPUパワーは必要です。 ファイルシステム＞TCP/IPのパケット変換といった処理も行う必要がありますからね、、 まぁどのくらいのパワーが必要かは、すでに書いてあるとおりモニターしてみないとわからないところもありますし、NICやハブにも、気を遣わないといけないと思います。 あとファイルサーバは、最近省電力化がすすんでおり、Transmeta Crusoeなどを使用したミニサーバーなども、売り出されているようです。 ある程度の処理速度を持ち、実用上問題なく発熱も少ないCPU(EzraコアのC3プロセッサ、Mobile Athlon XP、TualatinコアのCPUなど)を使うというのも、常時電源を入れておくサーバには、電気代の節約という意味でも考えなければいけないところですね。 C3などはファンレスでも動作するので、稼働部品を減らし故障率を下げる狙いも、ありますね、、 |
|
| 6. Reply: ファイルサーバ |
ah1cc-02p134.ppp.odn.ad.jp |
| Horisis さん |
Posted in 2002-10-17 01:45:41 |
| 複数のマシンから同時アクセスする事が多い場合には、HDDのシークタイムもレスポンスに利いてきます。 こればかりはRAIDではどうにもならないので、高速回転なHDDにするしかないですが。 また、特にATAの場合は、コントローラーチップやドライバにもよりますが シーケンシャルアクセス時とランダムアクセス時のCPU負荷は全く違うので注意です。 シーケンシャル時の性能はいいのに、ランダムアクセス時のCPU負荷が酷かったりと。 設計思想の問題とか、ヘッドシークの待ち時間の扱い方とかでしょうか。 |
|
| 7. Reply: ファイルサーバ |
28.pool0.newfamilytokyo.att.ne.jp |
| cdp-r1 さん |
Posted in 2002-10-17 02:07:19 |
| memoryの増設も効くんじゃないですかねぇ。 家にも似たような用途のサーバがありますが、メモリ増設は覿面に効きました つけっぱなしのマシンにクライアントからアクセスしたとき 2度目以降のアクセスのレスポンスが、少ないときから、メモリ増設したあとは かなり差があったような感じがします。 特にサーバ側のHDDにあるディレクトリファイル数が多くなればなるほど 感じました。 なんで、128Mはすくないんじゃないかなぁ〜とおもいます。 メモリ安いし、メインマシンに増設して、そこにあったやつから、引っ張ってくれば いいんじゃないかなぁと思ったり。 |
|
| 8. Reply: ファイルサーバ |
193.220.82.3 |
| tacco さん |
Posted in 2002-10-17 04:19:53 |
| みなさんレスありがとうございます。 こんな抽象的な質問に、こんなにもたくさんご教授頂けるとは 思っておりませんでした。非常に参考になっております。 本当にありがとうございます。 正直なところ、皆さんにお返事を返させて頂きたいのですが、 あまりスレッドが長くなりすぎてしまうのもご迷惑ですので、ちょっとガマンします。 ＃スレッド元(質問)だけでも長いのに・・・。(^^; 必要ないかと思いましたので、質問では割愛させていただきましたが、 後にこのスレッドを参照される方のために、 一応カンタンにネットワークの構図(?)を説明させていただきます。 ケーブルは基本的にお手製ですが、一応(?)Gigabit Ether対応で エンハンストカテゴリー5のモノを使用しています。 HUBは2台あり、共に安物ですがストア＆フォワード方式の 10/100のスイッチングHUB(以下、SWとします)です。 SW1に、主に使用する6台前後のPCが接続されており、 さらにSW2とカスケード接続し、SW2の方に問題(?)のファイルサーバとMailServer(Linux)、 WebServer(Linux)が接続されていますが、100BASE-TXで接続されているのはFileServerのみで、 他のServerは10BASE-Tで接続されている、という状態です。 つまり、主に使用するPC群からファイルサーバへは、HUBを2回通す事になります。 ちなみに、これは常時稼動のPCはうるさいので、物置の中で稼動させる為です。 熱対策とかは・・・、ツッこまないでください。(^^; 多少は考えて設置しているので、多分大丈夫です。(大汗 ファイルサーバを作るに当たって、CPUの候補が二つありまして、 共にCeleronなのですが、300Aと566MHzがありました。 ただ、IntelのHPで確認したところ消費電力が19.5Wと11.9Wとありまして、 低電力＝低発熱ということで566MHzを選択しました。 300Aだと、450駆動させないと気が済まない(←貧乏性)ので・・・。 クロックアップしたファイルサーバも危険ですし。(^^; ＃余談ですが、Celeron566MHzが歴代Celeron(デスクトップ用)の中で ＃今のところ最も低電力で、最も耐高熱なんですね。 ホントはC3辺りで組みたいのですが、予算の関係で・・・。 でも、電気代とニラメっこして検討してみます。 また、Lunxさんがおっしゃっている音質の劣化、画質の劣化等は 今のところほとんど気になりません。 ただ、ワタシは多少の音飛び等も気にならないくらいの鈍感体質なので、 参考にならないかもしれません。。。ゴメンナサイ。 WELLNOWさんの2MByte/sのAVIは笑わせていただきました。 1分で120MByteって・・・、そんな動画入れたらHDDがいくつあっても・・・。(^^; でも、HDD周りが速いとSocket7でも問題が出ないものなんですね。 ファイルサーバの件に限らず、とても参考になりました。 友人からも言われましたが、PC内部のデータ転送速度と LANの速度なんて比較にならないくらい違う(PC内部が速い)のだから、 PC自体のスペックなんて気にしなくて良いのかと思っていましたが、 ウチに転がってるPentium120MHzじゃあんまりだろうしなぁ、なんて考えて どのくらいのラインのスペックが必要かと思い、皆さんに質問させていただきました。 ＃実は、本気でPentium120MHzマシンにATAカードを挿して ＃ファイルサーバを立てようかと考えてました。(^^; ただ、やはり具体的な数値は測ってみないと分からないですよね。。。 測り方の勉強も兼ねて、やってみようと思います。 チップセットによる転送速度の違いも試してみようと思います。 ちょうど、440BXのM/Bが余ってますので。 ただこのM/B、Coppermineが使えないので、どう比較しようか悩んでますが・・・。 また、メモリ増設の効果も試してみます。 ホントはファイルサーバ用に256Mのメモリを用意していたのですが、 どこかのHPでECC付きがファイルサーバに適しているような記事を読んだので、 少ないながらもECC付きで構築したんです。 ＃今、ECC付きってECC無しの2倍以上高いんですよね。(T.T) ただ、メモリの交換ならすぐ出来るので、試してみようと思います。 結果はまた報告させていただきます。 すみません、結局長くなってしまいました。。。。m(_ _)m ただ、もしご教授いただけることがありましたら、 まだまだ、よろしくお願いいたします。 |
|
| 9. Reply: ファイルサーバ |
tyo108.gate.nec.co.jp |
| masashi さん |
Posted in 2002-10-17 10:21:44 |
| >OS：WindowsNT4 WS SP6a 個人的には、これが一番足を引っ張ると思いますよ NT4WSは、WIN95をファイルサーバーにした場合とFTPサーバーなど大差ないと思いますが すでにcdp-r1さんがおっしゃられていますが、メモリ増設が一番効果絶大ですが、 NT4の場合、スループット設定がWSでは出来ません、この設定項目次第で、データ転送の速度や 大量のアクセスがあった場合、モロに差が出ます。 サーバーを立てるならServer専用のOSを使うのがやはりベストだと思います。 NT4ServerもしくはWindows2000Serverがいいと思います。 |
|
| 10. Reply: ファイルサーバ |
ip1b0767.osk.mesh.ad.jp |
| YMA さん |
Posted in 2002-10-17 10:22:24 |
| 初めて書き込みさせて頂きます 上記の構成ですと、ＯＳをNT4.0WSからNT4.0ServerもしくはWindows2000Serverに変更するのがパフォーマンスアップにつながると思います OSの価格を考えるとコストはかなりかかりますが^^; 某MSの資格取得勉強中に同じ構成のマシンにそれぞれをインストールして検証しましたがNT4.0WSをファイルサーバーとして使った時のネットワークのパフォーマンスはかなり悪いようです 経験談からですが、メモリ増設は複数（十数台）のクライアントＰＣからの同時アクセスにかなり有効でした 会社のファイルサーバーですが下記のスペックでいまだに現役で問題なく使えてます CPU：PentiumII300MHz MEMORY:512MBECC付き(増設前は64MB) HDD:4G*3(RAID5)+30G*2(ミラー) OS:WindowsNT4.0Server LAN:10BaseT |
|
| 11. Reply: ファイルサーバ |
ip1b0767.osk.mesh.ad.jp |
| YMA さん |
Posted in 2002-10-17 10:50:48 |
| Windows 2000 Advanced Server 120 日評価版 というのがかなりお安く(\1575)なっているみたいです あくまで120日限定の評価用ですが、ＯＳによるパフォーマンスの変化はご理解頂けるのではないかと思います http://www.microsoft.com/japan/windows2000/edk/default.asp |
|
| 12. Reply: ファイルサーバ |
ppp061127186015.adsl.flets.nmt.ne.jp |
| いしかわ さん |
Posted in 2002-10-17 19:21:11 |
| たしかにブロードバンドスピードテストでもNT4は速度が出ませんし、2000などのほうがより、よいのかもしれないですねぇ。 ただ、Server用OSというのは、どうなんだろうと、、最近はGigabitな環境もわりと安価ですから、そういうのに変更した方がよほど、パフォーマンスは上がると思いますが、、まぁ、数十台ではなく数台での、話ですけどもね、、(笑 |
|
| 13. Reply: ファイルサーバ |
193.220.82.3 |
| tacco さん |
Posted in 2002-10-18 03:18:50 |
| 皆様、ご教授ありがとうございます。 先ほど帰ってきたばかりなので、まだメモリ増設はして無いのですが・・・。 OSの違いと転送速度の違いという点は思いつきませんでした。 ぜひ、試してみたいと思うのですが・・・・、高いっす。(T.T) 気軽に試せる値段じゃないですねぇ。。。 というわけで、、 YMAさん、情報ありがとうございます。早速申し込んでしまいました。(^^; ただ、評価版なので今のファイルサーバではなく、別PCにインストールして NT4WSと比べてみたいと思います。 正規のものはとても買える値段じゃありませんが、体験はしてみたいと思います。 また、ついつい某オークションをのぞいてしまいましたが、 WindowsNT4Serverだったら正規のものでも比較的安価で売られてますね。。。 これならなんとか、、と思いつつ、Linuxという手も考えています。 ただ、主にWindowsアプリケーション用のファイルを収容するサーバですので、 万が一の場合に、比較的サルベージ(という言い方はちょっと大袈裟ですが)する方法の多い Windows系OSの方が安心なのですが、Linuxも勉強すれば何とかなる気がしなくもありません。 ＃英語とスキルに自信が無いので、ちょっと遠まわしな言い方です。(笑 ただ、いしかわさんのおっしゃるように、Windows2000Serverを購入するつもりであれば、 ウチのような小規模ネットワークなら、比較的安価になってきたGigabit Ether環境を 整えてしまう、というのも金額的に考えやすいですね。 皆様、ご教授いただき本当にありがとうございます。 おかげ様で色々試してみる事が出来そうです。 もしまだご教授いただけることがありましたら、 まだまだ、よろしくお願いいたします。m(_ _)m |
|
| 14. Reply: ファイルサーバ |
ip1b0767.osk.mesh.ad.jp |
| YMA さん |
Posted in 2002-10-18 09:26:58 |
| これも経験談からですが、あるユーザーにて クライアント３０台程度（ＯＳ混在） サーバー１台（WindowsNT4.0WS） の環境で「サーバーへのファイル転送レスポンスが悪いので何とかして欲しい」という話がありまして 某販売店さんが「100BaseTX化しましょう」と全装置を100BaseTX化しましたが状況はまったく変わらずじまいでした（もちろんユーザーはお怒り^^;） 結局サーバーをWindowsNT4.0Serverプリインストールのサーバーに変更して事なきを得ました NT4.0だとWS、Windows2000だとProfessionalにはネットワークのパフォーマンス設定が固定にされていますが、Serverだと設定が可能なんですよ(MTUやRWINではございませんGUIで設定が可能な項目ですので念のため)あとWSやProだと接続セッションが10迄ですしね GigabitEtherが数台〜数十台の環境に必要になるとはあまり思えませんが．．． 早いに越したことはないのでしょうが上記の様な例もありますので^^; |
|
| 15. Reply: ファイルサーバ |
proxy2.fjswa1.kt.home.ne.jp |
| BlackBox さん |
Posted in 2002-10-18 23:36:12 |
| WindowsNT ServerとWorkstation、Windows2000 ProfessionalとServerの違いは性能というよりライセンスです 特にクライアントが多い場合はライセンスの違いが結果として性能の悪化につながります tacco さんの想定する規模ならNT/2000 Server入れるよりはPC UNIX入れてSamba動かした方がコスト的にいいと思います ライセンスの問題はなくなるし、OSに倍の金をかけても性能は倍にはなりませんので |
|
| 16. Reply: ファイルサーバ |
193.220.82.3 |
| tacco さん |
Posted in 2002-10-19 07:32:38 |
| YMAさん、BlackBoxさん、ご教授ありがとうございます。 おかげさまで、ファイルサーバの構築の方向性がだんだん見えてきました。 考えてみれば当然ですが、ハードウェアを制御するOS側も 非常に重要な要素になってくるんですね。。。 せっかく評価キットを申し込んだので、Windows2000Advanced Serverと、 LinuxでSambaを立てた場合も、比較してみたいと思います。 ただ、Sambaの方は調整が非常に難しそうですが・・・。(^^; 素人が趣味で行っている範疇ですので、両者とも100％の性能を 引き出すことは出来ないと思いますが、素人目から見た 構築のしやすさ等も含めて比べてみたいと思います。 ＃Documentの多いLinuxか、直感的に分かりやすいWindowsか、 ＃ってとこでしょうか。(^^; 皆様本当にありがとうございます。 もしまだ、ふと思い出した事等ありましたら、 お教えくださいますと幸いです。 どうぞよろしくお願いいたします。m(_ _)m |
|
| 17. Reply: ファイルサーバ |
pd30f92.ykhmac00.ap.so-net.ne.jp |
| 通りすがり さん |
Posted in 2002-10-22 00:20:06 |
| ファイルサーバ、DBサーバは通常、1メモリ、2CPU、3Diskと言われます。 CDMA/CD方式ですと帯域の約30%を超えるとコリジョンが発生します。 具体的に例を挙げますとと、100MB LANでDVD相当のMPEG（VBR 8Mbps）を共有視聴と 仮定すると6台超えたあたりからパフォーマンスが急激に落ちてきます。 （VBRですとCBR4M〜5M程度ですから。） 同時に同一キャプファイルを読み込んだ場合、ネットワークOSの種類や設定にも よりますが先読みキャシュが効いてDisk I/Oはネックにならないでしょう。 これが別ファイルですと、Disk I/Oがボトルネックになり、3 4台でカクカク しはじめます。（でもこれはレアケースでしょう。） SOHO向けファイルサーバと言ってもクライアントが完全Diskレスマシン で無い限り、大したスペックは要求されないと思います。 今、使われている構成ですとメモリ増強だけで済むと思います。 思い出して下さい。3年前は500Mhzでハイエンドサーバだったんですから。 それから要求されるスペックはファイルサーバの場合、対して変わってません。 （まぁ、VIDEOサーバは別ですよ。） |
|
| 18. Reply: ファイルサーバ |
193.220.82.3 |
| tacco さん |
Posted in 2002-10-22 05:34:37 |
| 通りすがり さん、ご教授ありがとうございます。 当方の勉強不足でお恥ずかしい限りですが、 おっしゃることは大体理解できました。(^^; 分かりやすく説明していただき、嬉しい限りです。 帯域の30％でコリジョンが発生するのは知りませんでした。。。 以前、10BASE-T環境だった頃に使っていたリピータHUBに コリジョン検出ランプ(?)みたいのがあり、それが多く点滅すると 転送速度が急激に落ちる、みたいな事があって、気にはしていたのですが、 現在の安物スイッチングHUBになってからはそんな機能が無かったので、 気にもしていませんでした。 ただワタシの勉強不足で、コリジョンの発生とスイッチングHUBが どのように関係するのかよく理解できないのですが、 それはこの掲示板で質問するには不適切ですので 他の場所で勉強してきます。(^^; おっしゃるとおり、3年前は500MHzでハイエンドでしたね。。。 考えてみれば、100BASE-TXという規格(?)は3年前にはもうすでにあったのに、 今現在でも使われている事から考えれば、ナルホド、と思ってしまいました。(^^; きちんと数値を測らなければ言い切ることは出来ませんし、 ハードウェアやOSの選択、設定によるところですが、 500MHzという、その辺の数値が100BASE-TX環境でのファイルサーバの スペックのラインなのかもしれませんね。 ご教授ありがとうございました。m(_ _)m もう少し勉強してきます。(^^; |
|
| 19. Reply: ファイルサーバ |
yahoobb219017008002.bbtec.net |
| よねよね さん |
Posted in 2002-10-22 23:31:24 |
| >ファイルサーバ、DBサーバは通常、1メモリ、2CPU、3Diskと言われます。 それは初めて聞きました。ファイルサーバとDBサーバが同列に語られるんでしょうか？？？ できましたら、情報ソースを提示していただけないでしょうか？ >CDMA/CD方式ですと帯域の約30%を超えるとコリジョンが発生します。 CSMA/CD方式です。 それに、この根拠も教えていただけないでしょうか？ また、taccoさんも >現在の安物スイッチングHUBになってからはそんな機能が無かったので、 >気にもしていませんでした。 と書かれているように、一般にスイッチングHUBを使っている環境では、コリジョンは起こりえませんが．．． |
|
| 20. Reply: ファイルサーバ |
193.220.82.3 |
| tacco さん |
Posted in 2002-10-23 02:17:05 |
| よねよねさん、ご教授ありがとうございます。 お恥ずかしい限りですが、ネットワークに関しては 多少聞きかじった事がある程度の知識ですので、 コリジョン＝データ同士の衝突 スイッチングHUB＝リピータHUBと違い1対1で通信させるHUB くらいの認識しかありませんでした。 ＃その他、カット＆スルー方式やストア＆フォワード方式といった ＃方式の違いは多少勉強はしましたが、名前は知っている、というレベルです。(^^; ですので、コリジョンの発生要素等は全くもって知識が無いので ＃コリジョンが発生するのか、しないのかを含めて まだまだ勉強不足だな、と感じ入ってしまった次第です。(^^; ただ、こちらの掲示板はPC/AT互換機掲示板ですので、 ネットワークに関しては、別のところで勉強してきます。 でも、、、、 今思うと、当初のワタシの質問の仕方が曖昧ですよねぇ。。。。(^^; ファイルサーバと一口に言っても、サーバ自体の性能から クライアントの状況から、ネットワークの効率から等々考えると、 答えは一つではなく、数限りなくありますもんね。(ーー;) こんな抽象的な質問に快くお教えくださった皆様には 感謝の言葉もありません。 本当にありがとうございました。m(_ _)m |
|
| 21. Reply: ファイルサーバ |
c4350.isid.co.jp |
| よねよね さん |
Posted in 2002-10-23 10:00:41 |
| >コリジョン＝データ同士の衝突 >スイッチングHUB＝リピータHUBと違い1対1で通信させるHUB それで十分だと思いますよ。 すなわち、「1対1で通信＝衝突は起こらない」んですよ。（ストア＆フォワードで全二重通信しているという前提ですが、普通はこれを満たしていますので） >答えは一つではなく、数限りなくありますもんね。 そうですね、要件も千差万別ですからね。私が仕事で使うファイルサーバは1ファイル1GBになったり、数十人で同時に使ったりしますし。（というわけで、私のレスも taccoさんの環境で的確に当てはまっていないかも知れないですが．．．m(._.)m） ともかく、DISK I/Oを改善すれば、今度はネットワーク I/Oがボトルネックになり．．．と奥の深い世界です。(^^ゞ |
|
| 22. Reply: ファイルサーバ |
p29f66f.ykhmac00.ap.so-net.ne.jp |
| 通りすがり さん |
Posted in 2002-10-23 19:13:34 |
| >それは初めて聞きました。ファイルサーバとDBサーバが同列に語られるんでしょう >か？？？ >できましたら、情報ソースを提示していただけないでしょうか? 同列ではないですが各サーバH/W増設を行う優先順位としては 結果として同じ事になっています。 Netware、ORACLEのチューニング講習会では当然の事 にように語られると思います。 >CSMA/CD方式です。 >それに、この根拠も教えていただけないでしょうか？ RFCやIEEE802.2等の文献をよく熟読してください。 またネットワーク技術者の試験でも昔はよく出たと思います。 簡単に例えるなら高速道路での車の渋滞と同じです。 >と書かれているように、一般にスイッチングHUBを使っている環境では、 >コリジョンは>起こりえませんが．．． 識者が見れば判ると通り、共有型HUBが前提です。 また、基礎的な情報として記載しますが、 高速なNASとして利用されるよくEMCのストレージは言い換えますと 高信頼性なDiskキャシュのお化けです。 この事からもメモリキャシュが以下に有益化判ると思います。 最も高速なRAID0でWRITE BACK/THRUE設定切り替えをしてもメモリ1GB 増設する方が遥かにファイルサーバとして有益と私は思っています。 H/W増強でも足りず、原因が ネットワークの帯域であった場合、 1.帯域強化（スイッチHUB） 2.スイッチHUB（帯域強化） 3VLAN導入 4レイヤ3スイッチ 5レイヤ4スイッチ の順で強化だと思います。 もちろんネットワークトポロジの設計も重要です。 スイッチにしてもファイルサーバのような1対多接続ではコリジョンが減るだけで 帯域の使用率は60%を超える程、大幅に向上しません。 ここまでは余程大規模な映像サーバでないとやらないしょう。 |
|
| 23. Reply: ファイルサーバ |
yahoobb219017008002.bbtec.net |
| よねよね さん |
Posted in 2002-10-24 01:31:50 |
| >この事からもメモリキャシュが以下に有益化判ると思います。 >最も高速なRAID0でWRITE BACK/THRUE設定切り替えをしてもメモリ1GB >増設する方が遥かにファイルサーバとして有益と私は思っています。 おっしゃっているキャッシュの増設は、むしろDISK I/Oを高速化させることが本当の目的であり、メモリ増設は単なる1方策だと思いますが、いかがでしょうか？ >RFCやIEEE802.2等の文献をよく熟読してください。 >またネットワーク技術者の試験でも昔はよく出たと思います。 CSMA/CD方式は MAC副層のお話しですから、LLC副層を規定した IEEE802.2で、そんなに CSMA/CD方式について語られていましたっけ？（ちなみに一応、ネットワークスペシャリストは持っておりますが．．．） >1.帯域強化（スイッチHUB） >2.スイッチHUB（帯域強化） >3VLAN導入 >4レイヤ3スイッチ >5レイヤ4スイッチ >の順で強化だと思います。 コリジョンドメインの分割（1＆2？）、ブロードキャストドメインの分割（3＆4）、QoSや負荷分散（5）はすべて独立して考慮すべき事象であり、それらを「順番」に考えるのはいかがかと思いますが．．． |
|
| 24. Reply: ファイルサーバ |
p29cf2b.ykhmac00.ap.so-net.ne.jp |
| 通りすがり さん |
Posted in 2002-10-24 08:39:53 |
| >おっしゃっているキャッシュの増設は、むしろDISK I/Oを高速化させることが本当の >目的であり、メモリ増設は単なる1方策だと思いますが、いかがでしょうか？ Disk I/Oを減らす事が目的です。Disk I/Oを高速化する事とは目的の方向性が 全く異なります。尚、EMCのストレージを利用する場合、 高速性もさる事ながら、そのバックアップの高速性、信頼性、多大なオプション といった観点から採用するケースがほとんどです。 >CSMA/CD方式は MAC副層のお話しですから、LLC副層を規定した IEEE802.2で、そんな >に CSMA/CD方式について語られていましたっけ？（ちなみに一応、ネットワークスペ >シャリストは持っておりますが．．．） 疑ってはいけませんが、あまりに常識な話なので。。。。 ネットワークスペシャリスト、Netware、NT関連、ORACLEのベンダ系資格 持ってますが。。。 規定文書にはその仕組みが記載されています。その仕組みをみれば 識者は何故、帯域使用率が100%にならないか判断出来ると思います。 RFCの方には使用率記載があったと記憶しています。 少なくとも私の時には問題として出ましたけど >コリジョンドメインの分割（1＆2？）、ブロードキャストドメインの分割（3＆4）、>QoSや負荷分散（5）はすべて独立して考慮すべき事象であり、それらを「順番」に考 >えるのはいかがかと思いますが．．． どこぞのページで見た内容がそのまま出ているような気が。。。。 価格を見れば判る通り、順に上がっていきます。 ネットワークの問題として原因が初めから訴求出来る場合は その対処をすれば良いと思います。 書き方が悪いですが単なる強化ではなく強化検討ですね。 設計の仕方はそれぞれで結構だと思います。 このままだと議論が続きまし、正直、低レベルな話なので、今後は 控えさせて頂きます。今後も議論が必要であれば２ちゃんにでもスレ立てて 下さい。（お互いキツイ突込みが待ってるでしょうけど。） |
|
| 25. Reply: ファイルサーバ |
c4350.isid.co.jp |
| よねよね さん |
Posted in 2002-10-24 16:58:09 |
| >ネットワークの問題として原因が初めから訴求出来る場合は >その対処をすれば良いと思います。 >書き方が悪いですが単なる強化ではなく強化検討ですね。 >設計の仕方はそれぞれで結構だと思います。 > >このままだと議論が続きまし、正直、低レベルな話なので、今後は >控えさせて頂きます。 そうですね、お互いに見ているネットワークの規模や要件が違うのに、「自分はこう思う」なんてことを声高に言いすぎました。失礼を... >どこぞのページで見た内容がそのまま出ているような気が。。。。 いえ、別に私はどこも見ていませんよ。 |
|