サーバ業務周りの管理、運用について役に立ちそうなナレッジをまとめました。
長期的に書いているため用語に統一性がなかったり、不足分など随時修正したいと思います。

1. サーバ設計

サーバスペックはどうするべき？

最近はクラウドにて必要スペックを自由に決めることができるため、最低限必要なスペックは確保したい。そのため以下は検証、確認しておきたい。

スペック(CPU/RAM/Network)の最低要件は何か？
停止可能なサーバか？(スケールアウト、アップできるか？)

使用するOSは？

利用したいミドルウェアに依存します。また、Rethatのように有料か無料かも判断材料に入ってきます。例えば、Ubuntu、CentOSどちらも使える場合は、以下で判断すると良いかもです。

stable(安定ver.)なバージョンのOSを使う
他のサーバOSに合わせる
知見が多いOSで決める
最小のOS(minimal)を選ぶようにしましょう

CentOS開発終了について

CentOS開発終了が決定されており、最新のCentOS8は 2021年12月31日でサポートが終了します(ただしCentOS7は2024年6月30日までサポート)。 CentOSはCentOS Streamとなり、常に最新パッケージのみしか提供されないくなるため、MW以上の対応を常時やらないといけなくなります。

blog.centos.org

CentOSを導入される方はそのことを考慮した上で検討する必要があります。

ただ、Linuxディストリビューションはたくさんあるため、この機に色々冒険するのもありかと思います。また最近はクラウド利用が進んでいるため、提供されているOSを使えば、大きな負担にはならないはずです。

MWは何を使うべきか

OS同様MWにも注意が必要です

MWは必要な分だけインストールしましょう
stableなバージョンが存在しているため、最新かつstableなバージョンを使うようにしましょう

Debianであれば dpkg -l | grep <パッケージ名> 、RHELであれば yum list installed | grep <パッケージ名> で検索して無理のない範囲で最小構成を目指しましょう。

Webサーバ構築にはどちらを使うべき？Apache？Nginx？

Nginxにする必要が特にない場合はプリインストールされているApacheにしましょう。初期インストールされているものは推奨されているMWです。

サーバセキュリティで最低限押さえておきたいことは？

商用でサーバを使う場合最低限以下は確認したい。

listenしているポートは最低限か？
個人ユーザには最低限の権限のみ与えているか？(認可の話)
インターネットに出る際にはプロキシを使っているか？
アンチウイルスは使っているか？

listenするポートは最小限にしましょう

ss -auntコマンドや、lsof -iコマンドで必要なポートだけlistenするようにしてください。不明なポートはiptablesなどで閉じましょう。つまりインストールされているMWの使用ポートは全て把握する必要があります。

ファイアウォール設定で送受信IPアドレス、ポートの通信制御はしておきましょう

初心者の場合は以下でざっくり設定をします個人的な環境で設定を行う場合は

CentOS は firewalldコマンド
Ubuntu は ufwコマンド

より細かいフィルタ制御をしたい方は iptables(CentOS/Ubuntu共通) を使用します

外部に出る際にはプロキシサーバを経由するようにする

セキュリティリスクとして内部でデータが不正に取得されても外部に出なければ良いので、プロキシサーバを経由させるようにしてデータ流出を防ぎましょう
外部通信をするため毎回プロキシサーバの宛先を環境変数に設定をするようにしておくと良いとおもいます

随時パッチを当てるようにする

サポート切れや脆弱性のあるパッケージは随時アップデートを行いましょう使用しているOSでパッケージが古いかどうかは apt-cache などで確認できます

個人アカウントで変更系コマンドは実行させないようにする

個人アカウントは必要最低限の権限のみ付与しましょう。ホスト全体に影響がでるような変更は sudo をつけるようにします。

ログについて考えること

ホストが生成されるログはエビデンスにもなるため重要です。

必ず所有者をrootにします
特に理由がない場合は推奨されているrsyslogを使うようにする
必要なログだけ残し、容量圧迫につながるログは削除したり、ローテーションを計画しましょう

ストレージ容量には気をつける

Linux ではストレージ容量がいっぱいになると大半のコマンドが打てなくなり、最悪サーバ上のアプリは停止します。

crontabなどで常時ログローテションするか、定期的に古いログ等は削除する設計はしておきましょう
sshとdfコマンドを組み合わせて常にホストの閾値を以下であることを監視する
Zabbixなどの監視ミドルウェアを使える場合はそれを使う
パブリッククラウドの場合にはそれぞれ専用監視システムがあるためそれを使うようにする

データベースはどう決めたら良いか

データベースだけでも膨大に種類があるため、慎重に決める必要がある。以下の要件で決める。

複雑なテーブル要件と各テーブルのリレーションが必要
-> リレーショナルDB(OracleDB、MySQL、PostgreSQLなど)
key、valueのように単純なテーブル構成(各テーブル同士のリレーショナルもいらない)
-> NoSQL (Cassandra/MongoDB)

※Redisは特殊な用途で使われてるため、対象外。更なる検討が必要。

MySQLかPostgreSQLか？

よく出る話題です。以下要件で選択しましょう。

大規模なら多機能な PostgreSQL
小規模ならシンプルな MySQL

PostgreSQLは大規模対応のため、追記型アーキテクチャを採用しており、UPDATEを実行すると DELETE -> INSERTする形になっています。
MySQLような単純変換ではなく、実質2コマンドを実行するため小規模だとパフォーマンスが出ませんが、大規模での大量UPDATEとなるとINSERTの処理に探索が不要なためPostgreSQLの方が有利になります。

個人的にまずはMySQLを使用して、パフォーマンスが出なかったり、機能不足を感じた場合はPostgreSQLに移行するのもありかと思っています。

2.サーバ構築

環境変数の初期値

各ユーザのホームディレクトリには以下ファイルが生成されています。これはユーザログイン時に毎回実行されるもので必要に応じて環境変数を追加してデフォルト環境変数として扱えるようにします。

~/.bashrc
~/.bash_profile

sudoの際に別の環境変数を設定したい

visudo のsetenvで設定します。例えばsudo実行時は各ユーザ毎の実行ファイルを使うときになどが当たります。

%hoge        ALL=(ALL)       SETENV: /usr/bin/fuga

サーバ設定値の管理はどうするか？

監視系のように更新頻度の多いサーバ設定ファイルは、複数人数で何度も編集することによりファイルの中身が煩雑になったり、万が一ファイル損失した際、リカバリが難しくなってしまいます。できればgithubなどで管理し、crontabで定期的に git add -> git commit -> git push して管理しましょう。

Rootで直接ログインできないようにしましょう

特に理由がなければ、以下でrootでの直接ログインを不可にしておきましょう。

PermitRootLogin no

rootで作業したい場合は、ログイン後にsudoを利用してroot権限での作業をしましょう。そうしないと誰がrootで作業したのかログからはわからくなってしまいます。

visudoの落とし穴には気をつけよう

visudo内での設定順序によっては、sudoがうまく働かない場合があります。(例えば設定したのにNOPASSでsudo実行できないなど) これは visudo内のファイル設定が上から処理されるからです。例えば以下のように設定してしまうと①のユーザ設定が②で上書きされてしまいます。

Aユーザの設定 --- ①


Aユーザを含むグループの設定 --- ②

そのため、①のような小さい単位の設定を行う場合はvisudo内の下部に記載してください。また、そのようなトラブルを避けるため、include ディレクトリを設けて小さい単位の設定はその中で設定するルールにしておくと良いと思います。

ログ取得に条件式を設けて、明らかに不要なログは削除しましょう

rsyslogのRainerScriptによって設定ファイルにスクリプトを定義することができます。

www.rsyslog.com

※注意単純にif文を使えばRainerScriptを使用しているとみなされるだが、一部のrsyslogのレガシー設定と併用が不可能なため気をつける必要がある。またRainerScriptはrsyslogの機能の中でも比較的新しい機能であるためなるべく最新のrsyslogをインストールしてください。

rsyslogでログの受信制限を設定する

rsyslogの機能でratelimitが存在するためそれが一番簡単です。またこれも RainerScriptで設定が可能なためratelimit以外の複雑なログ処理を必要とする場合はRainerScriptを使いましょう。

ログのローテーションは設定しましょう

ログは増え続けるものなので必ず商用サーバにはログローテションは必要です。以下のように、一定周期でアーカイブサーバなどにローテーションしておきましょう。

# 以下をcrontabに設定する
find /var/log/ -mtime +365 -exec rm {} +;

systemctlのサービスを登録する方法

使用する実行ファイルは必要に応じてsystemctlで管理しましょう

vi /etc/systemd/system/<service名>.service

[Unit]
Description=<Description>   #Descriptionを書くことにより、systemctlコマンド実行時にサービス概要を確認できる
After=network.target syslog.target # 

[Service]
Type=simple #
ExecStartPre=/usr/local/sbin/<prestart時の実行コマンド>
ExecReload=/usr/local/sbin/<reload時の実行コマンド>
ExecStart=/usr/local/sbin/<start時の実行コマンド>
ExecStop=/bin/kill -s TERM $MAINPID

[Install] 
WantedBy=multi-user.target

ログイン時の注意喚起のためにmotdを使う

よくある話としては本番機と検証機を間違えないようにするために設定する
初心者向けにサーバの説明する時など

vi /etc/motd

##################
This is a Production  !!!!
##################

間違ってshutdownやrebootしないようにする

誤ったshutdownやrebootを防ぐにはいくつかの予防策があります。

shutdownやrebootの実行はroot権限が必要なため、例えばsudoでは実行できないようにすることで、個人アカウントで誤って実行することを防げます。

またmolly-guard を使う方法もあります。

sudo apt install molly-guard

これはsshでログインした時のみ有効ですが以下のようにshutdownしてもすぐにshutdownが実行されず、ホスト名を入力するように促されます。正しいホスト名を入力すればそのままshutdownが実行されます。

# shutdown -h now
W: molly-guard: SSH session detected!
Please type in hostname of the machine to shutdown:

危険コマンド対策

有名な例をあげると以下ですが、他にもたくさんあるので、誤って打ちそうなコマンドを探すと良いでしょう。

危険コマンド	説明
sudo rm -rf /	全てを無にする
sudo mkfs.ext4 /dev/sda	/dev/sdaとはOS実行に必要な情報が入る記憶領域なためこれを初期化すると・・・
mv /etc/* /dev/null	ありとあらゆる設定ファイルを無にする
dd if=/dev/random of=/dev/sda	/dev/sdaをランダムで上書きしてしまうので・・・

これらのコマンドは誤って打たないように同じ形のコマンド実行をaliasで実行不可な状態にしたり、スクリプトで監視したりする方法があります。

shellscriptを作るまでの流れ

構築を行っていく際に同じ工程が何度も発生するのであれば、コマンドを結合したり、for分使ったりしてどんどんスクリプト化していきましょう。その方がコマンドの打ち間違えも防げます。

繰り返し実行するコマンド群が発生
↓
コマンドを改修(コマンドの結合やスクリプト化)
↓
shellscriptを本格的に作成する

sshにも多要素認証を

セキュリティの重要性が高まる中でsshも多要素が求められてきたようです。商用でのサーバ管理では多要素認証はsshのみならず全て必須になっていくでしょうから、sshの多要素認証対応はしておきましょう。

sshのデフォルトポートは変えておきましょう

インターネット直接繋がっているホストはDDoS攻撃の的にされるので、必ずssh や ftpなどのログイン、転送系のポートは変更しておきましょう。セキュリティを強固にしておけば不正侵入は防げますが、DDoSによるリクエストをL4で受け取ってしまうとサーバダウンに繋がってしまいます。

3.サーバ運用

サーバ運用の際に使うコマンドについてまとめました

最低限知っておいた方が良いsshコマンドの使い方

インフラ業務ではsshとても多様するため正直すべてのオプションを把握しておいた方が良いですが、

コマンドオプション	説明
ssh -i <秘密鍵のパス>	鍵認証でアクセスする際に使います
ssh -p <ポート番号>	sshポートは22ですが、それ以外でlistenされているホストにログインする際には指定する必要があります
ssh -L <転送元ポート番号>:<転送先ホスト名またはIP>:<転送先ポート番号>	ポートフォワードに使います
ssh -A	一般的には秘密鍵の転送を経由する踏み台サーバにすることにより、ローカル環境にある秘密鍵で踏み台先のホストにアクセスできるようにします
ssh -o ServerAliveInterval=<keepaliceパケットの送信間隔>	意外によく使うオプションで、特にパブリッククラウドでのインスタンスでは長期間のセッションを防ぐため一定時間でsshセッションを切断する仕組みが儲けられていますこのオプションを使うことにより一定間隔でkeepaliveパケットを投げることができるため、予期しない切断を防ぐことができます

ssh コマンドについて

sshコマンドの後ろにコマンドを書くことによってssh先でコマンドを実行できます

ssh  <ユーザ名>@<ホスト名>  <ssh先で実行したいコマンド>

スクリプト化した際など、パスワードなしでこれを実行したい場合は sshpassコマンドを併用します。

ログインマクロについて

Windowsの場合

Windowsですと、ターミナルツールとしてteratermが一般ですが、teratermをインストールする際に一緒にインストールできる LogmeTT の使用をお勧めしたいです。とても使いやすいマクロツールでこれを使えば私が知る限りののログインプロセスは自動化できます。

ttssh2.osdn.jp

Macの場合

Macの場合はlinuxと同様に ssh_config を作成するようにします。また、ターミナルツールには iTerm2 を使用します。

多段ポートフォワード

インフラ構築の場合、大抵は踏み台サーバを経由して対象サーバの構築や閲覧を行うかと思います。踏み台先のサーバに例えば80番ポートでブラウザアクセスしたい場合はポートフォワードを使用します。また踏み台を２回経由しないといけない場合などでは多段ポートフォワードを実行することによってブラウザアクセス等が可能になります。

ローカルPC
↓
踏み台サーバ１
↓
踏み台サーバ２
↓
対象サーバ(8080ポートでアクセスしたい！)

上記のような場合は以下手順でsshコマンドを実行します

# ローカルサーバで実行
ssh -L 2222:<localhost>:22  <ユーザ名>@<踏み台サーバ１>

# 踏み台サーバ１で実行
ssh -L 2223:<localhost>:22  <ユーザ名>@<踏み台サーバ２>

# 踏み台サーバ2で実行
ssh -L 8081:<localhost>:8080  <ユーザ名>@<対象サーバ>

ブラウザ localhost:8081 にアクセス

鍵転送について

踏み台先から鍵認証対象サーバにアクセスしたい場合は秘密鍵を踏み台に置かずに鍵転送を使用しよう。秘密鍵は絶対に複製せず、ローカルにのみ置いて管理してください。

# ssh エージェントを有効化
$ eval `ssh-agent`

# 転送したい秘密鍵を sshエージェントに登録する
$ ssh-add ~/.ssh/id_rsa

# 鍵転送を実行してログイン
$ ssh -A <ログインユーザ>@<秘密鍵を使用したいホスト>

# 秘密鍵を使いたいホストにてsshエージェントが有効であることを確認(Agent名が)
$ ssh-add -l
Agent pid 37343

公開鍵の配布

Ansibleで一般的になったような気がしますが、公開鍵の転送には ssh-copy-id を使用します。

linuxには複数のテキストエディターが存在する

比較的有名なテキストエディタは以下でvimだけ使えれば良いと思います。

Vim
nano
Emacs

vimについて知っておくべきこと

vimにも種類がありまして、vim.tinyが最小構成のもので機能が限られます。
最初は使いやすいですが、すぐに編集スピードに限界を感じるかと思います。

bashではなくzshでプリインストールされているvimは比較高機能なものであり、これに慣れておくことをお勧めします。

実践Vim 思考のスピードで編集しよう！ (アスキー書籍) | ＤｒｅｗＮｅｉｌ, 新丈径 | 工学 | Kindleストア | Amazon

nanoは使いたくない vim が使いたい！

linux でvisudoなどを利用する際にテキストエディタがnanoになっている時があるのですが、vimに変えたい場合は以下で変更できます。

sudo update-alternatives --set editor /usr/bin/vim.basic

一時的にvimにしたい場合は以下のようにコマンド前に環境変数を入れて変更する

EDITOR=vim visudo

画面をクリーンしたい時

teratermのプロンプトが見えていない時や、termの表示が荒れてしまったときに、よく ctrl+c や ctrl+z したり、 enter 連打したりと散見されますが、想定外のコマンドが実行されてしまったり、ジョブを誤って停止してしまったりとトラブルに繋がってしまう可能性があるため、 ctrl+l で対処するようにしましょう。

ctrl+lでプロンプトに何もないこと確認した上で Enterを連打してログの見やすさを意識すると良いかと思います。

ショートカットキーは使いましょう

ctrl+a,e をはじめ、bash、zsh上では様々なショートカットが使えるため、覚えるようにしましょう。

パッケージ更新ができない

古いLinux OSの場合は参照先のパッケージサーバがサポートを終了している場合があります。その場合は /etc/apt/source.list にてパッケージサーバを変更する必要があります。大抵はアーカイブとして見つかりますが、見つからない場合は早期にOSのバージョンアップが必要になります

cp、mvコマンドなどでのpath指定

pathは一歩間違えると事故につながりますので、短く書くように工夫しましょう。

cp /var/log/source_log /var/log/copy_log ❌

cp /var/log/{source_log, copy_log} ⭕️

秘密鍵の強度

技術の発展とともに秘密鍵の安全性も毎年変わってきます。秘密鍵は一定の安全性を確保する必要があるため、使用時期に応じてNISTが定めている暗号とハッシュを使う必要があります。

https://www.ipa.go.jp/files/000013413.pdf

ssh-keyscan

sshでログインすると ~/.ssh/known_hosts というファイルがssh実行元に作成されますが、これをログインする前に作成しておきたい場合はssh-keyscanコマンドを使用します。初回のログインでこの ~/.ssh/known_hosts を作るか選択する必要があるのですが、これがスクリプト作成や自動化などでの妨げになります。 ssh-keyscanコマンド を使った後にsshログインすれば聞かれなくなります。

vimで中身全部削除

コマンドモードで 1GdG と入力。間違えたらuでUNDOしましょう。

vimを使う時はInsertモードのまま移動しないように工夫しよう

ついInsertモードで移動しがちだが、vimは極力カーソル移動を減らすように設計されているのでコマンドモードを駆使して移動しよう。行移動なら 1G 3G G など

vimで置き換えする際にはCheckオプションをつけましょう

ファイル内で置き換えを行う際にはコマンドモードにて :%s/<置換前>/<置換後>/gc としましょう。 cをつけることによって置換を一つずつ確認することができます。

sudo vimはやめよう

sudo vimでファイルを編集してしまうと所有者がrootでないファイルも所有者rootにされてしまいます。大きなトラブルの元につながりますので、特に理由がない場合は代わりにsudoeditを使うと良いでしょう。

ログ確認をコマンドで

journalctl

重たいファイルはscpではなくrsyncで転送しよう

例えば転送に何時間もかかるようなファイルの移動はscpではなくrsyncを使って転送するようにしましょう。

shutdown をhistoryから消すとトラブル回避に繋がる

shutdownコマンドやrebootコマンドや影響範囲の広い変更コマンドは一度打った後にhistoryから削除しましょう

vi ~/.bash_history

$? $! とは

$?は終了ステータスです。直前のコマンドやスクリプトが正常に終了したかどうかを確認することができます。
特にスクリプト作成で使うことが多く、終了ステータスが 0以外(異常終了)の場合は例外処理に流したり、エラーメッセージに分岐させたりします。

<スクリプト or コマンド実行>

# 標準出力が0なら直前の正常終了、異常終了
echo $?

$! は直近で実行したプロセスIDを返します。
これもスクリプトで使われることが多く直前に実行したコマンドのプロセスIDを使って別処理に使ったりします。

エラーを隠す場合は

スクリプトなどでエラーが発生しても標準出力させたくない場合は以下のようにエラーを /dev/null に葬ってしまいます。

<コマンド実行> 2>/dev/null

tmux または screen でセッション共有をしましょう

商用環境で作業を行う際には複数のメンバが同じ画面を見ることになると思います。直接サブディスプレイで画面を共有しても良いですが、tmuxやscreenを使ってセッションを共有すると良いと思います。

また、sshでリモートログインしている中でコマンド実行中に作業者PCの異常で通信不可になってもセッションは残るため、商用環境での作業では必ずtmuxまたはscreenのいずれかを利用しましょう。

スクリプトでも応用が効き、複数セッションを同時に立ち上げて各セッションでスクリプトを実行することも可能です。

ttylog でttyを共有する

同じホストの他ユーザの実行画面を閲覧できます。商用環境で作業をする際に便利です。 tmuxとは違いセッションを共有するのではなくttyに標準出力された内容を他ユーザにも標準出力される仕組みのようです。そのためtmuxやscreenと違いセッションを奪うようなことはできません。

4. サーバ自体について

データセンタ作業では、日頃では中々触らないサーバ作業が存在します。またデータセンター作業に必要な準備については以下に記載しています。

どのようなサーバが業務で使われているか？

メーカ別の主なサーバ製品は以下になります。メーカによって仕様が全く違うため、使用する際にはメーカー、製品毎の検証は必要です。

サーバ名	感想
HPE ProLiant	数あるサーバの中で一番使いやすいサーバでした。IPMIの管理ユーティリティがしっかりとしていて、故障率も低かった印象です。
Fujitsu PRIMERGY	故障率がまあまあ高かったですが、ユーティリティ周りがしっかりとしていたため、使いやすい印象です。
DELL Power Edge	ネットワーク周りに難ありでした。想定と違う動き(linkup/down)をする印象でHPEと違い、扱いづらかった印象です。
Supermicro	確か割安のサーバでしたが、故障率が高く、IPMIユーティリティにもいくつか難ありの印象です。

OpenRack

サーバは一般的にとてもでかく重いですが、以下のような小さなサーバも存在します。これはクラウド需要を見越して、限られたスペースに必要なだけのサーバをできる限り効率的に収納するためのプロジェクトのようです

www.ctc-g.co.jp

Open Compute Project Japan | オープンコンピュートプロジェクトジャパンは、OCP (Open Compute Project) の日本コミュニティです。

IPMI とは

一般コンシューマー向けPCではほとんど見かけませんが、業務系サーバでは IPMI *1と呼ばれる特殊なインターフェースモジュールが存在します。 業務系サーバではこれがとても大事で主に遠隔からのサーバ管理に使われます。

主にやれることは以下になります

電源オンオフ
サーバ詳細情報の閲覧、変更
ファームウェアのバージョンアップ
OSへのイメージマウント〜OSインストール
OS上の操作
REST APIでのサーバ操作

最近ではこのIPMIのREST APIを使用して、BIOSの設定、ファームウェアのVer調整などを構築自動化する動きもあるようです。

IPMIの必要性

IPMIは業務系サーバでは必須のインターフェースモジュールです。例えばデータセンタ現地での作業を行った後に、サーバのOS再インストールや再起動、OS、フォームウェアのアップグレードなどが必要になった場合、遠隔でこれらを行おうとすると、少なくともOSが起動してIPがアサインされるまではネットワーク疎通性がなくなってしまい管理ができなくなってしまいます。

これは場合によっては再度IPアサインをデータセンタ現地で行わないといけないため、業務上では大きな遅延に繋がってしまいます。そのためIPMIでのIP設定はある意味、業務上での命綱となります。

そういった理由もあり、IPMIは物理的に独立したモジュールをサーバ本体に繋ぐような形で実現しており、OSの影響を受けないように設計されています。

BIOS (UEFI/Legacy)について

f:id:thelarklife1021:20210427063323p:plain

BIOSには大きく分けてUEFIとLegacyの２種類が存在しており、日頃見かける上記のようなBIOS画面はUEFIの画面になります。 UEFIは選択式のBIOSで、初心者でも簡単に操作が可能です。

対してLegacy BIOSは CLIのBIOSで、専用コマンドを入力して操作を行います。 UEFIでは対応していない機能が存在していた場合、Legacy BIOSに切り替えて設定を行います。

意外と言葉は出てくるので、概要だけ知っておくと良いと思います。

サーバでもSFPの時代

SFPは光インターフェースモジュールのことで、高速な通信を必要とする場合に使用されます。

ひと昔まではCiscoやJuniperなどのネットワーク機器に使われるのが一般的でしたが、最近ではサーバにも使われるようになっているようです。

また、一般コンシューマ向けのPCでも10GbE以上を搭載したい場合はこれを使う場合があります。サーバだけでなくストレージでも使うので、データセンタ業務で必ず目にすると思います。

SFPの拡張カード

f:id:thelarklife1021:20210427064406p:plain

Amazon | QNAP(キューナップ) 10GbE SFP デュアルポートネットワークカード QNAP専用 LAN-10G2SF-MLX | QNAP(キューナップ) | ネットワークカード通販

f:id:thelarklife1021:20210427064327p:plain

Amazon | 10GBase-T SFP+モジュール, Cisco互換, Ubiquiti, Netgear, D-Link, Supermicro, TP-Link, Broadcom, Linksys, Avago, QNAP, RJ45コネクタ 10Gb/s 30m【5年保証】 | ADOP | パソコン・周辺機器通販

*1:Intelligent Platform Management Interface