Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
鮫鮫鮫#Techlunch
Search
Livesense Inc.
PRO
April 21, 2014
Technology
0
60
鮫鮫鮫#Techlunch
鮫! 鮫! 鮫!
2013/02/05 (水) 12:00-13:00 @ Livesense TechLunch
発表者:鈴木 翔一郎
Livesense Inc.
PRO
April 21, 2014
Tweet
Share
More Decks by Livesense Inc.
See All by Livesense Inc.
EM候補者向け転職会議説明資料
livesense
PRO
0
5
コロナで失われたノベルティ作成ノウハウを復活させた話
livesense
PRO
0
73
株式会社リブセンス 会社説明資料(報道関係者様向け)
livesense
PRO
0
350
転職会議でGPT-3を活用した企業口コミ要約機能をリリースした話
livesense
PRO
0
1k
株式会社リブセンス マッハバイト_プレイブック
livesense
PRO
0
400
Tech Award 2021 選出方法
livesense
PRO
0
1k
株式会社リブセンス エンジニアリング組織を支える風土と制度
livesense
PRO
0
520
株式会社リブセンス・マッハバイト 採用候補者様向け資料
livesense
PRO
0
210
株式会社リブセンス・転職会議 採用候補者様向け資料
livesense
PRO
0
2k
Other Decks in Technology
See All in Technology
[2024年3月版] Databricksのシステムアーキテクチャ
databricksjapan
8
1.9k
VS CodeでAWSを操作しよう
smt7174
2
170
Cloud Native Java with Spring Boot (CNCF Aarhus, April 2024)
thomasvitale
1
130
Google Cloud の AI を支える裏側のインフラを垣間見る!
maroon1st
0
210
シン・Kafka / shin-kafka
oracle4engineer
PRO
7
2.7k
ここが嬉しいABAC ここが辛いよABAC #再解説+補足編
masahirokawahara
1
230
[PlatformCon 24] Platform Orchestrators: The Missing Middle of Internal Developer Platforms?
danielbryantuk
1
180
20240416_devopsdaystokyo
kzkmaeda
1
190
Reducing Cross-Zone Egress at Spotify with Custom gRPC Load Balancing Recap
koh_naga
0
140
「共通基盤」を超えよ! 今、Platform Engineeringに取り組むべき理由
jacopen
25
5.9k
"好き"との生活/Regularly update profile with GitHub Actions
judeeeee
0
150
カオナビの利用実績をアウトカムへつなげる旅 / example-of-data-management-startup-in-kaonavi
kaonavi
0
120
Featured
See All Featured
Scaling GitHub
holman
457
140k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
273
13k
Stop Working from a Prison Cell
hatefulcrawdad
266
19k
A Tale of Four Properties
chriscoyier
150
22k
The Cost Of JavaScript in 2023
addyosmani
14
3.8k
Code Reviewing Like a Champion
maltzj
513
39k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
60
14k
WebSockets: Embracing the real-time Web
robhawkes
59
7k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
76
41k
How to name files
jennybc
64
92k
For a Future-Friendly Web
brad_frost
171
8.9k
[RailsConf 2023] Rails as a piece of cake
palkan
22
3.9k
Transcript
鮫! 鮫! 鮫! CTO室 鈴木 翔一朗
None
None
None
None
None
鮫! 鮫! 鮫! ネットワークはなぜつながるのか Deep Dive CTO室 鈴木 翔一朗
None
DHCP アドレス取得
DHCP Dynamic Host Configuration Protocol • PCへのIPアドレス割当 • PXE boot
: サーバセットアップ • Vitual Box VMの起動
None
DHCP 大事なんです いいんです DHCP!!!!!!
Broadcastを使用している事に注意
gateway, DNS等 割当可能なパラメタは多い
DHCPはルータ越え られないんです DNS割当できなきゃ yum updateこける んです いいんです DHCP!!!!!!
名前解決
DNS 割当 端末 DNS割当 クライアントPC DHCP Vitrula Box DHCP 推奨
DHCPを使っても、同じIPアドレスが 割り当てられる事が多いです。 Staticに設定するならば、Virtual Box内部の仮想ネットワークを正しく 理解し、gateway, DNS等の設定が 必要。Virtual Boxから外部ネット ワークへのNATでハマる事もあり。 サーバ機器 /etc/resolv.conf でstaticに定義
ルーティングテーブルに基づき パケットを送信
Longest match 法則 例 : 宛先 192.168.20.24 192.168.0.0/22 gw N/A
: 該当せず 192.168.0.0/16 gw 10.49.0.254 : 優先する 0.0.0.0/0 gw 180.214.38.254 : 優先しない Windows端末やネットワーク機器では、 metric, Adminitrative Distance等の概念あり
ARPテーブルに基づき next hopのMACアドレスをlook up
ARPテーブルにhitしない場合は、 ARP リクエストを送信
DNS query 送信
DNS タイムアウトはくせもの 多くのミドルウェアが名前解決に依存している DNS障害時は多くのミドルウェアが名前解決待ち の状態になり大規模障害を引き起こしやすい Timeoutを短めにする事で被害を軽減できるが、 それでもある程度の被害は避けられない
DNS timeout 設定例
怖いんです DNS 障害!!!!!!
HTTP connection 確立
3way handshakeによるコネクション確立
上位Layerでtimeoutが定義されていない場合 約30秒程の待ち時間が発生 待ち時間はretry毎にベキ函数的に上昇
Retry回数は容易に設定変更可能 sysctl : net.ipv4.tcp_syn_retries = 5 Timeout時間はハードコードされている ref ; include/net/tcp.h
CentOS 6.4くらいからTimeoutが3秒から1秒に 減ったので、総待ち時間が180秒から30秒に
gateway 冗長化 ISP業者 冗長化
ゲートウェイ冗長化 HSRP VRRP GLBP Cisco 独自 IEEE 標準 Cisco独自 Udp
1985 proto 122 udp 3222 一番実績豊富 IEEE 標準とは名ばかり 宛先MACアドレスやVRRP GROUP等について、独自 実装しているソフトウェ アが多いです。 ベンダー混在は極力避け る事が望ましいです。 負荷分散機能が実装 されたプロトコル。 他プロトコルに比べ 高機能だが、実績が 少なく使うには人柱 になる覚悟が必要。
Protocol number 全ての通信はTCP, UDPのみではありません。 TCP, UDPはProto 7, 19のIPです。 Proto 122のvrrpは以下のように指定します。
ISP 冗長化 方法 GLBP IGP/BGP ISP業者との事前取り決めが必要 調整工数が大きいですが、一度構築して しまえば安定して動く事が多いです 例 :
リブセンス – ビットアイル間 static route with tracking ある場所をping等で監視し、監視結果に 応じでstatic routeが変わります。 机上デバッグが非常に困難で、事前に入 念なテストをしないと、酷い障害につな がります。 例 : 管理本部
HSRP
実演中
IGP
Static Route ルータ2台程度までの小規模向け設定 ルータが増えると、設定工数が指数函数的に膨 れ上がる 障害発生時に自動的に切り替わらない IGP
(Interior Gateway Protocol) 経路情報を自動的に交換してくれる
Static routeが 許されるのは 小学生までだよねー
IGP 比較 プロトコル 説明 RIP レガシーなルーティングプロトコル “最大ホップ数15”等の様々な使いづらい制約がある OSPF 各ルータのリンク情報を収集し、ダイクストラ法に基づ いて最短経路を算出。
最も汎用的で最も実績豊富なプロトコル ISIS 各ルータのリンク情報を収集し、高速ダイクストラ法に 基づいて最短経路を算出。 OSI参照モデルに基づかず、非IPもルーティング可能 実績は皆無ですが、googleはISISを採用 EIGRP Cisco独自のプロトコル。OSPFに比べて、高速な切り替 わりが実装されている等のメリットがあるが、 Ciscoにベンダーロックされてしまうのが難点。
デフォルトは30秒程度で切り替わります Hello timerを短くする事で切替を早められます が、flappingに弱くなるデメリットがあります
OSPF
BGP
BGP AS (Autonomous System)間のルーティング Flapping対策のため、切り替わりは緩やか 様々な属性情報を付与して経路を送付
どの属性を優先させるのかはASのポリシー次第 local pfre > AS PATH > MED
BGP
実演中
DSR 負荷分散
負荷分散方式 方式 サーバ 負荷 学習 コスト DSR (L4LB) 小 大
宛先MACアドレス変換による負荷分散 戻りパケットはLBを経由しないよう設計 BIG-IP, keepalived NAT (L4LB) 中 中 IPアドレスを変換 戻りパケットがLBを経由するよう設計 ログ集計, 送信元制御など業務要件への配慮 BIG-IP, keepalived Proxy (L7LB) 大 小 代理アクセスによる負荷分散 ログ集計, 送信元制御など業務要件への配慮 Layer7制御が可能 BIG-IP, apache, nginx, HA-proxy, mysql-proxy DNS 小 小 名前解決による負荷分散 MyDNS
業務もインフラも 両方分からないと メンテできないんです ロードバランサー!!
None
仮想IPをListenする仕組み Loopback I/F (ARPに応答しないよう注意) NAT で問答無用でListenしてしまう
None
proxy 負荷分散
HTTP proxy
REMOTE ADDR書き換え livesense 独自拡張モジュール
apache 最低限の業務要件なら普通のmod_rpafでもok ubuntuはapt-getで一発インストール可 Nginx header 書き換え 駆使 HttpProxyModule 使用
どんなプロトコルも一長一短です。 特にLB関連は、業務要件に応じた構成を採用して 頂ければと思います。
おまけ GNS3 とっても便利なんです CTO室 鈴木 翔一朗
このネットワーク環境を5分で構築します もう3分頂ければIPv6も設定します
ルーティングのお仕事をすべて湖山さんがやるの は無理があるので、実機orエミュレータ検証がで きるレベルのエンジニアがもう一人いると助かり ます。 GNS3に興味を持って頂けましたでしょうか…