検証を詳しく知ろう!③ ~性能試験編~

ベル

前回の授業に引き続き「性能試験」について、もう少し詳細に解説してみたいと思いますが、まずは、「正常系試験」が問題なく完了していること、「異常系試験」で想定通りに迂回できていることが大前提です。どうしたらいいのかわからない方は、以前の授業の「正常系試験編」、「異常系試験編」からお読みください。

 

検証を詳しく知ろう!① ~正常系試験編~

検証を詳しく知ろう!② ~異常系試験編~

 

それでは、最後に「性能試験」についてまとめておこうと思います。性能試験とは、使用されるネットワーク機器の性能が設計通りに満たされているかをチェックする試験となります。大抵の場合は、以下の2つの観点で試験することが多いです。

 

 

 

スループット試験

よく搭載されている機器のスループットと言うとインターフェイスの仕様通りに動作すると思っている方もいますが、そんなことないんです。使用している機能によってスループットは大きく変化します。

 

代表的なところで言うと、WAN区間で使用されるQoSIPSecですね。この機能を小型ルータで使用すると100Mbpsのインターフェイスだったとしても10Mbps以下に性能が落ちることがあります。これはインターフェイスから出ていく前に優先制御処理や、暗号化処理に時間を要して性能が出ないためになります。このように、使用される機能によってスループットに大きな影響を与えることがあるため、WAN区間のスループットは必ず検証する必要があります。

 

代表的なフリーソフトは『nana』ですね。ソフト自体はすごく単純で、TCPとUDPで送受信をポート単位で指定することが可能です。もちろん、負荷試験機を購入して試験するのが一番ですが、とてつもなく高価なのでフリーソフトでも十分だと思います。以下からダウンロードが可能です。

https://www.vector.co.jp/soft/winnt/net/se168678.html

 

 

負荷試験

負荷試験が必要となるのは、対象機器に負荷が集中するポイントで行われることが多いです。例えば、NATの機能を使っている機器では、負荷が上昇する可能性が高いです。NATテーブルに1エントリあたり160バイトのメモリを消費するとCiscoでは公表しているので、まずはシステム要件とメモリ消費量を掛け合わせて確認してみましょう。

 

その後、机上で検討した結果通りになるかを検証で試してみるようにしましょう。もし想定と異なるようでしたら原因をしっかり調べておくことで、導入後のトラブルを削減することが出来るようになります。

 

本番と同じ通信でNATエントリを作成するのは難しいのですが、単純にNATエントリを作りCPUとメモリにどれだけの負荷がかかるかは、フリーソフトを使うと意外と簡単にできます。僕がよく使うのが、『ポートスキャナー』です。これによりTCPの1~1999までのポートをスキャンしてくれるので、NATエントリを大量に作成してくれます。悪いことに使ったりしないようにしてくださいね!

https://www.vector.co.jp/soft/winnt/net/se322399.html

 

このようにして負荷がかかる部分をしっかり特定して、システム要件通り(少し多め)の負荷をかけてみて、耐えられるかを検証しておきましょう。これが本番稼働した後に不備が発生してしまうと、最悪、スペックの高い機器に無償交換することにもなりかねません。手を抜かずにきちんと検証して結果を残すようにしましょう。

 

おまけ

おまけと言ってしまうと怒られてしまうかもしれませんが、本来の検証とは違った観点で検証する場合がありますので、それも紹介させていただきます。

 

手順の検証

検証の最後に手順の検証を含める場合があります。手順の検証とは、商用環境に追加設定をする場合などに、機器にログインする手順や、投入するConfigの妥当性などを検証することを指します。「そんなの適当にログインして投入ConfigをコピペすればOKでしょ?」と思われるかもしれませんが、それは違います。

 

例えば、ルータにACLを追加する場合、一度、インターフェイスのACLを外して、新しいACLを投入して再度インターフェイスにACLをあてる手順で実施すれば問題なくできますが、ファイアウォールであれば通信断が発生します。それは、ファイアウォールは、デフォルトでは何も通信させない使用となっているためです。これを知らずに設定してしまうと作業中にログインできなくなってしまうなんてこともあります。

 

また、IOSのバージョンにもよりますが、QoSの設定なんかは、正しい手順で設定しなければ優先・帯域制御が出来ないなんてこともよく聞く話です。そのため、きちんとした設定変更手順で実施して、問題なく設定が反映されることを確認しておくことが重要となります。

 

機器交換の手順検証

ネットワーク機器に限らずですが、モノは壊れることが前提です。壊れたら交換するのは当たり前ですが、その手順については検証されないことが多いです。そのため、実際に運用が始まると故障交換が出来なくて困ることがたまにあります。特に、あまり使われないような機器や機能を導入していると、故障交換が出来ずにパニックになり、誤った交換手順で実施して被害を拡大してしまうこともあります。そんな風にならないように、導入実績のない機器に対しては交換手順まで検証しておくことをおすすめします。

 

この検証をするにあたって、以下の観点で整理して実施することが大切です。

 

 

導入する場所によっては、パソコンの持ち込み・持ち出しNGのところもあります。それなのに交換時に現地でコマンドをたたいて設定変更・確認するような手順では意味がありませんよね。そんな風にならないように導入する場所にルールをしっかりとヒアリングしておくようにしましょう。

 

次の交換実施者のスキルですが、これも重要な要素の1つです。交換作業者によっては、パソコン操作が不得意で故障機器を取り外して、新しい機器を置くだけしか出来ません!なんていうこともあります。それなのに、複雑な作業やコマンドで確認してもらうような手順ではうまくできず交換時間の遅延でユーザに迷惑をかけてしまうことにもなります。そんな風にならないように、どの程度のスキルの人が交換対応するのかを事前に知っておくことが大切です。

 

このようにどのような環境でどのような作業者が実施するのかを事前に知ったうえで検証することで、より効果的な検証にすることができます。自分の常識やスキルをベースに考えないように注意しましょう。

 

まとめ

ベル

今回の授業はここまでです。僕がここまでいくつかの会社やプロジェクトで検証の実態を見てきましたが、正しい検証を出来ている現場は多くありません。もちろんコストや納期で検証を簡易的に実施して終わらせてしまうこともありますが、正しい検証方法知った上で、試験項目を削減するのはいいですが、むやみに削減するのはやめましょう。結果として、何ひとつ試験している意味がなくなってしまうことにもなりかねないので!

 

 

【ホームルーム(商品紹介)】

商品紹介 ~ネットワークエンジニアの便利アイテム!~

商品紹介 ~ネットワークのお勉強に役立つ商品①~

商品紹介 ~ネットワークのお勉強に役立つ商品②~

商品紹介 ~出張時の必須アイテム~

 

Follow me!

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です