MacでVPN接続でメトリクスチェックするときにハマったこと

環境

事象

  • VPN(PPTP)接続自体はできている
  • MacからVPN経由でメトリクスをチェックしようとしてもBrowserからどうしても接続できない

MTUのサイズ

  • VPN(PPTP)接続でMTUのデフォルトが1500になっている
    • 下記コマンドでMTUを適切な値に設定してあげる
    • 私の場合は1000にすると問題ない速度でつながるようになりました
sudo ifconfig ppp0 mtu 1000

VPNのプライオリティを上げる

  • どうやらデフォルトだとVPN接続よりも他の接続(Ethernet)等が優先され、VPN経由で接続ができていない様子
    1. 「システム環境設定」を開く
    2. 「ネットワーク」を開く
    3. ネットワークの一覧が表示されている下の「⚙」マークをクリックし、「サービスの順序を設定」をクリック
    4. VPN(PPTP)を一番上にする(使用しているネットワーク(Ethernetなど)よりも上にすればOK
    5. 「OK」をクリック

「AVB/EAV」をoffにする

  • Marvericsでは「AVB/EAVモード」がデフォルトでONになっている
    1. 「システム環境設定」を開く
    2. 「ネットワーク」を開く
    3. 「Ethernet」の「詳細...」をクリック
    4. 「ハードウェア」タブをクリックし、「AVB/EAVモード」の✓を外す
    5. 「OK」をクリック

やっと見れるようになった

■

外付けHDDを扱うときの忘備録

2TB以上のパーティションを扱う場合

  • 外付けHDDの認識された場所を確認する
  • (気になるgdisk)
    sudo parted -l
  • パーティションをきる
    sudo parted /dev/sdb
  • フォーマットする
    sudo mkfs.ext3 /dev/sdb1

2TB未満のパーティションを扱う場合

  • 外付けHDDの認識された場所を確認する
    sudo fdisk -l
  • パーティションをきる
    sudo fdisk /dev/sdb
  • フォーマットする
    sudo mkfs.ext3 /dev/sdb1

memo::RackTables

RackTablesに関するメモ

  • 本家URL

    • デモページを見ることができる

  • memo

  • 所感

    • ラック、サーバ情報、ポート、IPなどの情報を管理できて便利そう
    • サーバの台数が増えてきたら使いたい気持ちが強くなりそう
    • 色々な項目を管理できるので、必要なところピックアップして使うとよさそう

  • 注意

    • 日本語で説明されているページが少ない

コマンドを履歴(history)に保存しない

万が一の時に備える

rmコマンドなどの破壊的コマンドを履歴に保存していて、誤ってファイルを削除してしまったりしないように対策。

zshの場合

.zshrcに下記を記述すればok

  • rmを使う場合、先頭に空白を挿入
    alias rm=' rm -i'
  • 先頭に空白があるコマンドを履歴に保存しない
 setopt hist_ignore_space

bashの場合

.bashの場合、「alias rm=' rm -i'」としても、先頭の空白がエスケープされてしまい、うまくいかない。 なので、2パターン対応方法が考えられる。

パターン1：破壊的コマンドを使用する際に、必ず先頭行に空白を入れるようにする

この場合、.bashrcには下記を記述すればok

  • 先頭に空白があるコマンドを履歴に保存しない
    export HISTCONTROL=ignorespace
パターン2：破壊的コマンドを正規表現で履歴から除く

この場合、下記のように.bashrcに記述すればok

  • 正規表現に一致するコマンドを履歴に保存しない
    export HISTIGNORE=rm*

※ この場合、「sudo rm」は履歴に保存されてしまうので、下記のように記述してあげれば良い

    export HISTIGNORE=rm*:'sudo rm*'

以上です。

最後までお読み下さり、ありがとうございました。

誤っている部分がありましたら、ご指摘頂けますと幸いです。

ルータ、lvの冗長化：VRRP

VRRPの重要単語

  • VRRPパケット
    • 仮想IP、仮想ルータID、プライオリティなどの情報が入っている
    • マスターノードからマルチキャストアドレス（244.0.0.18）へと投げられる
  • 仮想ルータID
    • 同一ネットワーク上で複数のlvがActiveでいても、VRRPパケットによる混乱が起きないようにするための値
  • プライオリティ
    • 一番値が高いBackupノードがマスターノードとなる
    • Backupノードのうちどのノードがマスタノードとなるかを決めるための値
  • プリエンティブモード
    • ONのとき
      • マスターノードよりもプライオリティが高いノードがあったら、マスターノードが稼働していてもフェイルオーバーする
    • OFFのとき
      • マスターノードが正常稼働していれば、プライオリティが高いBackupノードがあったとしてもフェイルオーバーしない
  • 仮想MACアドレス
    • IPアドレスとMACアドレスの両方を引き継ぐ
    • gratuitous ARPが届かない機器があるとその機器との通信が出来なくなるので、それを避けるためにいっその事MACアドレスごと引き継ごうという発想
    • 主にL2スイッチのMACアドレスの学習状態の更新のためにgratitous ARPは使われる

keepalivedでのVRRPの実装

  • ploblem
    • linuxは複数のMACアドレスをもてない
    • => gratuitous ARPで解決する必要がある
    • eth0, eth1それぞれに設定が必要
  • gratuitous ARPでMACアドレスの変更を確実に伝える工夫
    • grap_master_delay
      • failoverした瞬間はネットワークが安定していない事が多く、指定した秒数後にgratuitous ARPを送るようにする
  • eth0, eth1それぞれについてVRRPの設定をしてあげる

IPVSでのWebサーバの冗長化

冗長化 ipvs linux lb dns

Webサーバの冗長化の方法2種類

  • DNSラウンドロビン（DNS）
    • デメリット
      • サーバの数だけグローバルアドレスが必要
      • 均等に分散されるとは限らない（DNSへの問い合わせをキャッシュするため）
      • サーバがダウンしても気づかない（ヘルスチェック、フェイルオーバーの仕組みと併用する必要がある）
  • ロードバランサ
    • 特徴
    • メリット
      • 一つのIPへのリクエストを複数のサーバへ振り分ける事が出来る
      • ヘルスチェック機能
    • デメリット
      • 高価
      • 運用への不安

IPVS（IP Vertual Server）用のミドルウェア

  • ipvsadm
  • keepalived
    • C言語のデーモン
    • ヘルスチェック機能
      • HTTP_GET
      • SSL_GET
      • TCP_CHECK
      • SMTP_CHECK
        • HELOコマンドの発行と応答の確認
      • MISC_CHECK
        • 外部コマンドの実行と終了コードの確認
    • ipvsadmコマンド
    • 設定ファイル（/etc/keepalived/keepalived.conf）
      • lvs_sched（スケジューリングアルゴリズムの選択）
        • どのWebサーバに優先してrequestを投げるのか
      • lvs_method（構成の選択）
        • NAT構成（lvs_method NAT）
        • DSR構成（lvs_method DR）
          • responseがlvsを経由しない。
          • 高トラフィックに耐えられる負荷分散に適している
          • 異なるサブドメインからの通信の場合、Webサーバがグローバルアドレスの処理が出来なければならない。

スイッチの種類

  • L4スイッチ
    • パフォーマンスを重視したいとき
    • トランスポート層までの情報を扱える（TCPヘッダなどのプロトコルヘッダの内容を解析して分散先を決定）
    • クライアントの通信先はリアルサーバ
  • L7スイッチ
    • 柔軟な設定を重視したいとき
    • アプリケーション層までの情報を扱える（アプリケーション層の中身まで分析して分散先を決定）
      • URL
      • リクエストを画像専用のWebサーバへ転送したりできる
      • session情報を元に、同一のsessionIDのリクエストを同じサーバに振り分ける事が出来る
    • クライアントとロードバランサの間・ロードバランサとリアルサーバの間の二つのTCPセッションが張られる

Webデータの流れ

  • クライアントPCからWebサーバまで

    1. Webブラウザからrequest
    2. 名前解決@DNS
    3. Webサーバがrequestを受け付ける
    4. Webサーバが静的コンテンツか、動的コンテンツかを判断
    5. データの取得（「システムコール」として実行）
    6. サーバ内のHDDから取得
    7. アプリケーションサーバへ問い合わせ
      1. NICに対してネットワーク通信がrequest
      2. スイッチ経由でアプリケーションサーバへの問い合わせ

  • Webサーバからアプリケーションサーバまで

    1. requestがNIC経由で、カーネルが割り込み処理として受け付ける
    2. スレッドがWebサーバからのrequestを受け付ける
    3. スレッドが「システムコール」としてDBへ問い合わせる
      • DBサーバへはNIC経由で問い合わせる

  • アプリケーションサーバからDBサーバまで

    1. DBのプロセスがrequestを受け付ける
    2. キャッシュにあるかを確認（あればデータを返す）
    3. 「システムコール」としてHDDヘrequestを送る
    4. HDDからrequest元のプロセスへデータを送る
    5. プロセスはメモリにデータをキャッシュとして保存
    6. データ（requestの結果）をアプリケーションサーバへ送る

  • DBサーバからアプリケーションサーバまで

    1. NIC経由でデータはスレッドへ渡される
    2. スレッドでファイルを作成（ERBファイルからHTMLファイル作成とか）
    3. Webサーバへデータを送信

  • アプリケーションサーバからWebサーバまで

    1. NIC経由でスレッドへデータが渡される
    2. スレッドからブラウザへデータを渡す
    3. ブラウザへデータが反映される