2010年02月
2010年02月28日
先日、以下の記事を書きました。
2010年02月26日：回線の増強
お客様から、かなり満足いただけたようで僕としてもとてもうれしいです。ということでやや詳しく内容を書きたいと思います。
まず最初は以下のような状況でした。
Before
ここでは拠点ごとのセグメントしかなく、1拠点1セグメントで運用されていました。そして拠点Bについては、すでにPCの台数も多く、運用の限界が近づいていました。IPアドレスの重複もよくおきていたようですし、トラフィックの低下やループの発生で全体のネットワークが停止するなど、毎日なんらかのトラブルが発生していたようです。
さらに、拠点間のトラフィックが多いことから、ルーターが毎日のようにハングアップしていたようです。
これらについて、「とりあえずなんとかしたい」という相談を受けたのがそもそも発端でした。
ネットワークの利用状況をヒアリングすると以下のとおりでした。
・拠点間の通信が多い
・セグメントAとセグメントBではそれぞれ2社が利用している。
(つまり2社が同一セグメントで運用されていました。)
・トラフィックデータはイラストレータなどの画像関係
・ルーターがハングアップするので外出もままならない
・ループが定期的に発生するのでなんとかしたい
・大規模な構成変更について運用停止を伴う場合には慎重に行いたいし、できれば平日に行いたい
この状況を聞き、またトラブルの切り分けの容易さなどを考え、L3を使ったネットワークを提案しました。
■提案
ここで拠点ごとにセグメントを分割し、1社1セグメントがいいのではないかと思いました。責任の点やトラフィックの影響、セキュリティなどからです。しかし機器代がかかることや、大規模なので比較的長時間の運用停止が発生することがデメリットです。
なおこの構成では、既存の100M回線はバックアップとして残してあります。予算との兼ね合いで、1Gのみでも問題ありません。ただし回線が停止した場合には目も当てられない状況になってしまいます。
この時点ではまだ弊社の実績が無いため、正直ここまで受け入れていただくのは難しいのではないかと考えていました。
そこで現実的な案として以下のような提案をしました。
提案
ここでトラフィックについて大変デリケートに考えていたので、1Gの回線を引く提案をしました。本来であれば100Mでも大丈夫だと思いますし、予算も抑えられるのですが速度重視ということでこちらにしました。
またL3はとりあえず利用せずにルーターをセグメントごとに置くことにしました。セグメントの分割は、クライアントの設定変更や工場の機器設定変更が必要になるため、最低限B拠点のみとしました。
既存環境がほぼ残るため、少数の機器の設定変更で完了すること、大きな影響が出にくいことから、この構成を実行し、様子を見る事になりました。
その作業が先日の記事に書いたとおりです。
もともとサーバーなどの機器がボトルネックになっているのではなく、ネットワークが原因だったのでかなり改善されました。
これによって、当初のヒアリングで聞いた問題点について、ルーターは落ちなくなったそうです。ループは現状発生していませんが、仕組みで回避する設定は今回は行っていません。作業は平日(金曜)の夜19時〜23時で完了しました。なお実質的には21時ごろに作業完了しましたが、テスト等も含めて完全に終わったのは23時を過ぎたころでした。
2010年02月26日：回線の増強
お客様から、かなり満足いただけたようで僕としてもとてもうれしいです。ということでやや詳しく内容を書きたいと思います。
まず最初は以下のような状況でした。
Before
ここでは拠点ごとのセグメントしかなく、1拠点1セグメントで運用されていました。そして拠点Bについては、すでにPCの台数も多く、運用の限界が近づいていました。IPアドレスの重複もよくおきていたようですし、トラフィックの低下やループの発生で全体のネットワークが停止するなど、毎日なんらかのトラブルが発生していたようです。
さらに、拠点間のトラフィックが多いことから、ルーターが毎日のようにハングアップしていたようです。
これらについて、「とりあえずなんとかしたい」という相談を受けたのがそもそも発端でした。
ネットワークの利用状況をヒアリングすると以下のとおりでした。
・拠点間の通信が多い
・セグメントAとセグメントBではそれぞれ2社が利用している。
(つまり2社が同一セグメントで運用されていました。)
・トラフィックデータはイラストレータなどの画像関係
・ルーターがハングアップするので外出もままならない
・ループが定期的に発生するのでなんとかしたい
・大規模な構成変更について運用停止を伴う場合には慎重に行いたいし、できれば平日に行いたい
この状況を聞き、またトラブルの切り分けの容易さなどを考え、L3を使ったネットワークを提案しました。
■提案
ここで拠点ごとにセグメントを分割し、1社1セグメントがいいのではないかと思いました。責任の点やトラフィックの影響、セキュリティなどからです。しかし機器代がかかることや、大規模なので比較的長時間の運用停止が発生することがデメリットです。
なおこの構成では、既存の100M回線はバックアップとして残してあります。予算との兼ね合いで、1Gのみでも問題ありません。ただし回線が停止した場合には目も当てられない状況になってしまいます。
この時点ではまだ弊社の実績が無いため、正直ここまで受け入れていただくのは難しいのではないかと考えていました。
そこで現実的な案として以下のような提案をしました。
提案
ここでトラフィックについて大変デリケートに考えていたので、1Gの回線を引く提案をしました。本来であれば100Mでも大丈夫だと思いますし、予算も抑えられるのですが速度重視ということでこちらにしました。
またL3はとりあえず利用せずにルーターをセグメントごとに置くことにしました。セグメントの分割は、クライアントの設定変更や工場の機器設定変更が必要になるため、最低限B拠点のみとしました。
既存環境がほぼ残るため、少数の機器の設定変更で完了すること、大きな影響が出にくいことから、この構成を実行し、様子を見る事になりました。
その作業が先日の記事に書いたとおりです。
もともとサーバーなどの機器がボトルネックになっているのではなく、ネットワークが原因だったのでかなり改善されました。
これによって、当初のヒアリングで聞いた問題点について、ルーターは落ちなくなったそうです。ループは現状発生していませんが、仕組みで回避する設定は今回は行っていません。作業は平日(金曜)の夜19時〜23時で完了しました。なお実質的には21時ごろに作業完了しましたが、テスト等も含めて完全に終わったのは23時を過ぎたころでした。
2010年02月27日
あるとき突然メールで、セミナーへの参加のお誘いをいただきました。なんとそのお誘いを頂いた方が、フィールドSEあがりの安納です の安納さんだったのです。とても光栄なことなので、ぜひ参加させてください！ということで、今日に至りました。
そもそも僕自身は中小企業向けの運営をしているので、比較的各製品については広く浅くのスタンスです。
ただし立場的にサポートを求められることがとても多いので、浅い知識とはいっても、使えるだけの知識ではなく、サポートもできるぐらいの、それなりの知識だと思っています。
詳細については、他の参加者の方がとても詳しいレポートを書いていますので、そちらを参考にしていただければと。
TFの集い 特別編「ありがとう Active Directory 10周年」：フィールドSEあがりの安納です
色々注目するべきところはあったのですが、いくつか挙げると、
・ActiveDirectory の構成方法が昔と違ってきている
→ 回線の太さによるところが大きい / サーバーを少数で運用するのが主流
・グループポリシーのトラブルシューティング
→ 適用の順番を意識する / アクセス権の付与状況 / DNS / トラフィック調査
・ADSI
便利。でも昔触ったときはちょっと難しい印象だったので、もう少し勉強します。
ということで、大変興味深い話を聞くことができました。これからもこうしたセミナー関係には積極的に参加したいと思います。
そもそも僕自身は中小企業向けの運営をしているので、比較的各製品については広く浅くのスタンスです。
ただし立場的にサポートを求められることがとても多いので、浅い知識とはいっても、使えるだけの知識ではなく、サポートもできるぐらいの、それなりの知識だと思っています。
詳細については、他の参加者の方がとても詳しいレポートを書いていますので、そちらを参考にしていただければと。
TFの集い 特別編「ありがとう Active Directory 10周年」：フィールドSEあがりの安納です
色々注目するべきところはあったのですが、いくつか挙げると、
・ActiveDirectory の構成方法が昔と違ってきている
→ 回線の太さによるところが大きい / サーバーを少数で運用するのが主流
・グループポリシーのトラブルシューティング
→ 適用の順番を意識する / アクセス権の付与状況 / DNS / トラフィック調査
・ADSI
便利。でも昔触ったときはちょっと難しい印象だったので、もう少し勉強します。
ということで、大変興味深い話を聞くことができました。これからもこうしたセミナー関係には積極的に参加したいと思います。
2010年02月26日
印刷関係の企業様がお客様でいます。製造業のCADもそうですが、印刷関係も非常に大きなファイルを取り扱います。そして大きなファイルを扱う場合、速度や安定性がシビアに求められます。
今まで他社が構築している環境に、僕が新しい担当者ということで、色々提案や作業をすることになりました。かれこれ1年ぐらい担当しています。
そしてNWの構成図を見る限りでは、この規模でよくこの構成だなぁという印象でした。ちょっとした作業をするだけで、ずいぶん速度が改善するのに。そのように思っていたので、提案をしていました。
比較的早い段階で提案は通ったのですが、ユーザーさんに影響がでるということで、慎重に作業を進めていました。そして順番に作業を進めているうちに、速度が遅いので何とかして欲しいという話になったのです。ユーザーに影響が出ることについて、説明を行い、了解をもらった上で回線の増強に着手をしました。
拠点間の通信が特に遅かったのですが、今までの回線に追加してもう1回線引きました。そして大きなデータを扱う部署については、こちらの回線を使うように設定しました。
設定を開始したのが夜だったので、完了したときの動作確認ではあまり変化が無いか、少し早い程度の印象だったようです。その場ではあまり満足頂けていないような雰囲気で、ちょっと申し訳なく思ったぐらいです。お客様もずっと「ちょっと早い感じはするけど、今は社員もいないから、トラフィックが少ないだけかもしれないしね」そのように言っていました。
1週間をすぎて、「トラブルの連絡もありませんし、安定していますか？」そのように聞いてみたところ、「今まで1時間ぐらいかかっていたファイルのコピーが、数秒で終わるようになった！」そのように言ってもらいました。
おかげさまでお客様には大満足を頂けたようです。よかった。
ちなみに、何も特別な方法を行ったわけではなく、今まではブロードキャストとか、余計なトラフィックが流れていることや、ルーターまでそういったパケットが届いており、無駄な処理にリソースを割り振られていました。今回はそれを分けただけです。本当に単純なことしかしていません。
なお、今後はL3を導入し、さらに効率化＋速度UPをしたいと思います。
今まで他社が構築している環境に、僕が新しい担当者ということで、色々提案や作業をすることになりました。かれこれ1年ぐらい担当しています。
そしてNWの構成図を見る限りでは、この規模でよくこの構成だなぁという印象でした。ちょっとした作業をするだけで、ずいぶん速度が改善するのに。そのように思っていたので、提案をしていました。
比較的早い段階で提案は通ったのですが、ユーザーさんに影響がでるということで、慎重に作業を進めていました。そして順番に作業を進めているうちに、速度が遅いので何とかして欲しいという話になったのです。ユーザーに影響が出ることについて、説明を行い、了解をもらった上で回線の増強に着手をしました。
拠点間の通信が特に遅かったのですが、今までの回線に追加してもう1回線引きました。そして大きなデータを扱う部署については、こちらの回線を使うように設定しました。
設定を開始したのが夜だったので、完了したときの動作確認ではあまり変化が無いか、少し早い程度の印象だったようです。その場ではあまり満足頂けていないような雰囲気で、ちょっと申し訳なく思ったぐらいです。お客様もずっと「ちょっと早い感じはするけど、今は社員もいないから、トラフィックが少ないだけかもしれないしね」そのように言っていました。
1週間をすぎて、「トラブルの連絡もありませんし、安定していますか？」そのように聞いてみたところ、「今まで1時間ぐらいかかっていたファイルのコピーが、数秒で終わるようになった！」そのように言ってもらいました。
おかげさまでお客様には大満足を頂けたようです。よかった。
ちなみに、何も特別な方法を行ったわけではなく、今まではブロードキャストとか、余計なトラフィックが流れていることや、ルーターまでそういったパケットが届いており、無駄な処理にリソースを割り振られていました。今回はそれを分けただけです。本当に単純なことしかしていません。
なお、今後はL3を導入し、さらに効率化＋速度UPをしたいと思います。
2010年02月25日
旅行に行くことが増えました。そしていつも思うことがあります。それは歴史的な名所でも「新しい」ということです。
これは補修という理由で古いものは撤去するなどして新たに作り直す場合があるからです。特にそう思うのが、今まで何度と無く見てきた各地のお城です。お城の場合は「復元」となっていることが多いのですが、復元されたお城というのは、結局のところ歴史的な建造物では無い様に思います。
もちろん復元に際しては、当時のものを忠実に再現するための最大限の努力を図っているようです。しかしやっぱりきれいですし、新しいのです。これを見ると、僕としてはあまり魅力を感じないように思えてしまいます。
神社仏閣については、○○地蔵などの場合には最近になって考えられたんだろうと思う箇所がいくつかあったり、離れた所にあるような建物の中には新しい仏像があることが多いです。
しかしメインとなる場所については、建物や仏像は当時のまま手入れをされて残っているので迫力を感じることが多いです。
日光では、改修工事が常にどこかで行われているようで、これもまた伝統だと考えると趣を感じます。
これは補修という理由で古いものは撤去するなどして新たに作り直す場合があるからです。特にそう思うのが、今まで何度と無く見てきた各地のお城です。お城の場合は「復元」となっていることが多いのですが、復元されたお城というのは、結局のところ歴史的な建造物では無い様に思います。
もちろん復元に際しては、当時のものを忠実に再現するための最大限の努力を図っているようです。しかしやっぱりきれいですし、新しいのです。これを見ると、僕としてはあまり魅力を感じないように思えてしまいます。
神社仏閣については、○○地蔵などの場合には最近になって考えられたんだろうと思う箇所がいくつかあったり、離れた所にあるような建物の中には新しい仏像があることが多いです。
しかしメインとなる場所については、建物や仏像は当時のまま手入れをされて残っているので迫力を感じることが多いです。
日光では、改修工事が常にどこかで行われているようで、これもまた伝統だと考えると趣を感じます。
2010年02月24日
Windowsパフォーマンスモニタ
リソース不足について - 第 1 回(第3回まであります)
Disk / CPU / Mem の利用状況、に応じて取得する値が違うと思います。それぞれ一番上のリンク先が参考になりました。
リソース不足について - 第 1 回(第3回まであります)
Disk / CPU / Mem の利用状況、に応じて取得する値が違うと思います。それぞれ一番上のリンク先が参考になりました。
2010年02月23日
2010年02月22日
ネットワーク機器を触っていると、よくこのCIDR表記にぶつかります。
そして僕はこれが全然覚えられない！ということでメモしておきます。
ちなみに、某大規模ユーザー様では、冗談のように /28 /30 なんていうサブネットを使っているのですごいなぁと思っています。
通常の企業であれば、まず /24 で十分だよ！
そして僕はこれが全然覚えられない！ということでメモしておきます。
ちなみに、某大規模ユーザー様では、冗談のように /28 /30 なんていうサブネットを使っているのですごいなぁと思っています。
通常の企業であれば、まず /24 で十分だよ！
| IP/CIDR | Subnet | ホスト数 |
| /32 | 255.255.255.255 | 1 |
| /31 | 255.255255.254 | 2 |
| /30 | 255.255.255.252 | 4 |
| /29 | 255.255.255.248 | 8 |
| 28 | 255.255.255.240 | 16 |
| /27 | 255.255.255.224 | 32 |
| /26 | 255.255.255.92 | 64 |
| /25 | 255.255.255.128 | 128 |
| /24 | 255.255.255.000 | 256 |
| /23 | 255.255.254.000 | 512 |
| /22 | 255.255.252.000 | 1024 |
| /21 | 255.255.248.000 | 2048 |
| /20 | 255.255.240.000 | |
| /19 | 255255.224.000 | |
| /18 | 255.255.192.000 | |
| /17 | 255.255.128.000 | |
| /16 | 255.255.000.000 | |
| /15 | 255.254.000.000 | |
| /14 | 255.252.000.000 | |
| /13 | 255.24.000.000 | |
| /12 | 255.240.000.000 | |
| /11 | 255.224.000.000 | |
| /10 | 255.192.000.000 | |
| /9 | 255.128.000.000 | |
| /8 | 25.000.000.000 |
