Akira's Blog

神奈川在住のITエンジニアの雑記です。主にプログラミング(Perl, Java など)やネットワーク技術についての小ネタを、ちょっとずつ書いていきます。

WSFCでHAクラスタを組むのにADは必須ではなくなったようだ。

Windows2016から、WSFC(Windows Server Failover Clustering)でHAクラスタを組むのに、AD(Active Directory)は必須(前提)ではなくなったらしい。

ADドメインはもう不要? ワークグループでクラスター作成が可能に――フェイルオーバークラスターの新機能(その3) (1/3):vNextに備えよ! 次期Windows Serverのココに注目(32) - @IT

 

Windowsのワークグループ構成を使ってクラスタ構成が組めるとのこと。しばらくクラスタ構築を行っていないので分からない分もあるが、WSFCでクラスタ構築する時の手間が少し省けそうな気がする。

ホスト名にアンダースコア (_) は許容されていない。

rfcを読むと、ホスト名に許容されている文字にアンダースコア(_)は含まれていない。

A "name" (Net, Host, Gateway, or Domain name) is a text string up
to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus
sign (-), and period (.). Note that periods are only allowed when
they serve to delimit components of "domain style names". (See
RFC-921, "Domain Name System Implementation Schedule", for
background). No blank or space characters are permitted as part of a
name. No distinction is made between upper and lower case. The first
character must be an alpha character. The last character must not be
a minus sign or period. ・・・

RFC 952 - DoD Internet host table specification

 

ITの世界では、名前中の区切り文字としてアンダースコアを入れることがあるが、ホスト名には入れてはいけないので、要注意である。あと、ホスト名の大文字・小文字は区別されない。

JavaのインタフェースとC言語のヘッダファイルの共通点

JavaのインタフェースとC言語のヘッダファイル(*.h)は、以下の点で共通点があると思う。

  • 実装クラスや実装ファイルが外部に公開する、定数、メソッド/関数の情報を記載する。
  • 機能を使う側、つまり取り込む側で インタフェースやヘッダファイルの情報(ファイル)を見つけられないと、コンパイルに失敗する。

まあ、Javaのインタフェースの場合、インタフェースで定義されている全てのメソッドについて、実装クラスでメソッドの実装を記載する必要があったりして、インタフェースとその実装クラスの関係性が、C言語のヘッダファイルと実装ファイルよりも密になっていると思うが、存在意義としては似ているものなのかな、と思った。

自宅インターネット接続

引っ越して新居でインターネット接続を行った時のメモ。環境は、回線が NTT東日本フレッツ光(ハイスピード・マンション・タイプ)で、 プロバイダはOCN。

インターネット接続の方式は、調べた限りでは以下の2つがあるようだ。

  1. NTT東日本から提供されたONU(Optical Network Unit:光回線終端装置)に直接、パソコンをつなぐ。
  2. 別途ルータを用意し、パソコン ----- ルータ ----- ONU とつなぐ。

 

1. の方法だと、提供されたONUにはイーサネットのポートが一つしかなく、無線アクセスポイントの機能もなかったので、同時にインターネット接続できるパソコンは1台に限られてしまう。あと、パソコンがスリープ状態になって復帰すると、接続が切れてしまい、その都度インターネット接続設定を行う必要があったため、2. の方法を検討することにした。

 

2. の方法ではバッファロー社のルータ(有線・無線対応)を購入し、ルータ ----- ONU と接続し、ルータの説明書に従いルータの設定を行った。この時は、スマホからルータにアクセスし設定を行ったが、パソコンからもできるはず。

なお、ルータの設定中、インターネット接続の検証を行う段階で、ルータからプロバイダのID/PWの入力が求められる。最初の機器(スマホ・パソコン)でこれを通過しておけば、その後別の機器でインターネットに接続する際は求められなかった。おそらく、最初の機器からのルータ設定の際、ルータがプロバイダのID/PWを記憶するのか?

あと、最初の機器からのインターネット接続検証で、何回かインターネットに接続できず失敗となったが、繰り返していたらいつの間にか接続できるようになった。少し時間がかかるものなのか?

 

幾つか疑問点は残ったが、これで家のパソコン・スマホからインターネットに接続できるようになった。

udpパケットを送信するスクリプト

指定したホスト、ポートに udpパケットを送信する perl スクリプト sendUdpData.pl を作成した。テストなどで、パケットキャプチャで取得したデータ(16進ダンプ文字列)を、好きな場所に送りたい場合に使う用途で作成した。

使い方は以下。

perl sendUdpData.pl -h 送信先ホスト -p 送信先ポート -d 送信データ(16進ダンプ文字列)


送信データ(16進ダンプ文字列)はファイルから与えることもできる。

perl sendUdpData.pl -h 送信先ホスト -p 送信先ポート -f 送信データファイル


何も引数を指定しないと、以下を実行する。

perl sendUdpData.pl -h localhost -p 162 -d "74 65 73 74"

「74 65 73 74」は「test」の16進ダンプ文字列である。


sendUdpData.pl

use strict;
use warnings;
use Socket;
use Getopt::Long 'GetOptions';

my $destHost = 'localhost';
my $destPort = 162;
my $sendData;
my $sendDataFile;

GetOptions(
    'host=s' => \$destHost,
    'port=i' => \$destPort,
    'data=s' => \$sendData,
    'file=s' => \$sendDataFile
);

if (!$sendData) {
    if ($sendDataFile and (-f $sendDataFile)) {
        $sendData = getDataFromFile($sendDataFile);
    }
    else {
        $sendData = '74 65 73 74'; # test
    }
}

if (length($sendData) == 0) {
    die("No data to send...");
}

$sendData =~ s/\s//g;
my $packedSendData = pack("H*", $sendData);

socket(my $socket, PF_INET, SOCK_DGRAM, 0) or die "Failed to create socket. $!";
my $addrBin = inet_aton($destHost);
my $sockAddr = pack_sockaddr_in($destPort, $addrBin);
send($socket, $packedSendData, 0, $sockAddr) or die "Failed to send. $!";

sub getDataFromFile {
    my $sendDataFile = shift;
    my $sendData;
    open(my $fh, $sendDataFile) or die "Failed to open $sendDataFile. $!";
    while (my $line = <$fh>) {
        chomp($line);
        $sendData .= $line;
    }
    return $sendData;
}

Cisco機器に対するSNMPリクエスト

Cisco機器に対してSNMPリクエストを行うと、機器のCPU使用率が高騰することがあるようだ。

IP簡易ネットワーク管理プロトコル (SNMP) は高いCPU使用率を引き起こす - Cisco

 

CPU使用率が高騰する理由は以下の通り。(上記のページより抜粋)

ネットワーク管理ステーションは、他のネットワークを学習するために、ルート テーブル全体に関してルータにクエリーを実行します。 この情報を使用して他のルータを見つけ、それらのルータの周辺ネットワークに関する情報についてクエリーを実行します。 このようにすることで、管理ステーションはネットワーク全体のトポロジを把握できます。ルータには、ルート検索を効率化するために、ハッシュ形式でルート テーブルが保存されています。 ところが、RFC1213 では、ルートの SNMP 応答については辞書順で返す必要があると規定されています。 そのため、ルータが SNMP 要求を受信するごとに、SNMP 応答の PDU を構築する前に、ハッシュ テーブルを辞書順にソートする必要があります。 ルート テーブルが大きくなるほど、ソートに必要な CPU の負荷も大きくなります。

 

ただ、上述のページに、SNMPリクエストを受けてCPU高騰しても、ネットワーク機器としての動作には影響がないという記載もあるので、これは気にしなくても良いのかもしれない。

CPU スケジューラでは、SNMP は優先順位の低いプロセスであるため、CPU リソースを必要とする別のプロセスが優先されます。 そのため、このシナリオでは CPU の使用率は急激に高まりますが、パフォーマンスには影響を及ぼしません。

 

MIB-II 配下の MIB はおおかた実装必須らしい

SNMPエージェントで、interfaces グループや ip グループなど、MIB-II 配下の MIB を実装していないものをたまに見かける。

しかしながら、rfc1213 によると、SNMPエージェントは MIB-II 配下の MIB はおおかた実装必須であるようだ。

https://www.ietf.org/rfc/rfc1213.txt

 

例えば、interfaces グループについては、rfc に以下の記述がある。

-- the Interfaces group

-- Implementation of the Interfaces group is mandatory for
-- all systems. 

ip グループについても、rfc に以下の記述がある。

-- the IP group

-- Implementation of the IP group is mandatory for all
-- systems.

「mandatory for all systems」とあるので、これらについては、どのSNMPエージェントでも実装が必須ということになる。

 

一方で、EGPグループについては、以下の記述になっている。

-- the EGP group

-- Implementation of the EGP group is mandatory for all
-- systems which implement the EGP.

この場合は、「implement the EGP」だったらという条件付きで、EGPグループのMIBが実装必須であるということになる。