タグ

ブックマーク / alpha-netzilla.blogspot.com (4)

  • zabbixでLLD(Low Level Discovery)を使いネットワーク情報を取得

    { "data": [ { "{#IFINDEX}": "10001", "{#IFALIAS}": "server001_eth0", "{#IFOPERSTATUS}": "up", "{#IFDESCR}": "GigabitEthernet1/0/1", "{#IFSPEED}": "1000000000", "{#IFINERRORS}": "0", "{#IFOUTERRORS}": "0", "{#ifHCInOctets}": "2653751290", "{#ifHCOutOctets}": "1363344818" }, { "{#IFINDEX}": "10002", "{#IFALIAS}": "server002_eth0", "{#IFOPERSTATUS}": "up", "{#IFDESCR}": "GigabitEthernet1/0/2", "{#IFS

  • F5 BIG-IP を運用する前に覚えておきたいポイント

    BI-IPを運用するうえで必要な最低限の知識をまとめておく。 blog内のコンテンツは下記の通りである。 ◆ ハードウェア ◆ 各種コマンド ◆ ログ ◆ 設定 ◆ 設定の永続化・同期 ◆ 設定のバックアップ ◆ 統計(mib情報) ◆ TRAP ◆ はまりどころ ※同様の機能を提供する機器としてA10があるだろう。 ◆ ハードウェア 【目視によるハードウェアの状態確認】 緑:active 橙:standby 【ステータス消しこみ】 active、standbyの切り替わり履歴があると点灯し続ける。 消去手順 1. 前面の☑ボタンを押す 2. clear all warnings alerts? 3. もう一度☑ボタンで実行 ◆ 各種コマンド 【停止処理】 ● 再起動 reboot shutdown -r now 【ハードウェア関連】 ※tmsh系のコマンドとb系のコマンドをできる限り併

  • MII監視からARP監視によるボンディング切り替えへの変更方法

    サーバのボンディング(bonding)の切り替えが起きず、 トラフィックを処理できない事象が発生した。 問題への対応を検討する。 ◆ 障害内容 サーバ側で、ボンディングのActive-Backup モード(mode=1)を利用し、 障害の検知方法としてMII監視を使っていた。 しかし、L2スイッチがリンクがアップしている状態で故障したため、 サーバ側では異常を検知できなかった。 その結果サーバ側での経路切り替えが起きず、トラフィックを処理できなくなった。 L2SW     L2SW |   ⇒ × |  左経路から右経路にbonding切り替えが起きない SERVER ◆ ボンディング切り替えの監視方法の変更絵検討 ボンディングのActive-Backup モード (mode=1) では障害の監視方法として MII監視とARP監視の2通りの設定がある。 ボンディングを切り替えるためのトリガ

  • kernelチューニング

    linuxサーバのOS全体に効くカーネルパラメータのチューニング箇所と その設定値、またその理由をまとめておく。 あくまで自分の環境ではこうした、というだけであり、 提供するサービスごとに検討が必要である。 どこをどう変更するのか、または変えないのか、その判断材料にはなるだろう。 ※ユーザ単位でシステムリソースに制限をかける場合をこちらを参照してほしい。 以下は/etc/sysctl.conf で設定するものとする。 ● 大規模サイト用チューニング kernel.pid_max 動作:pidの最大数 設定値:131072 理由:pidを枯渇させない vm.max_map_count 動作:mmapやmalloc時にメモリを仮想空間にマッピングできる最大ページ数 設定値:300000 理由:マッピングできなくなる事態を防ぐ net.core.somaxconn 動作:接続(ソケット)キューの

  • 1