iptablesのリスタート時にモジュールをアンロードさせない方法
最近のlinuxカーネルではデフォルトで、 iptablesリスタートするとiptablesモジュールがいったんunloadされる。 このとき、TCP接続元ホストやそのホストでwindow scale optionが有効になっている場合、 (1) windowサイズを正しく認識できなくなる (2) 張られているTCPセッションがESTABLISHED ⇒ INVALIDとなる (3) TCPセッションが切られる アプリによっては再接続等で問題がわからないかもしれない。 しかし、TCPセッションが切れることで問題が発生するアプリも存在するだろう。 そのため、iptablesモジュールをunloadしない設定にしておくかどうかを検討する必要がある。 ● 確認 ① window scale option の確認 # cat /proc/sys/net/ipv4/tcp_window_scalin
iptablesのip_conntrackが上限に達した場合の対処方法
ログを確認していると何かエラーが出ていた # tail -f /var/log/messages ip_conntrack: table full, dropping packet iptablesのセッション管理テーブル(ip_conntrack)が上限に達したようである 解消方法は二つ。 ① ESTABLISHEDな状態を記録する期間を短くする ② ip_conntrackに記録できる上限数を上げる 【OSパラメータの変更作業】 ◆ 現在の使用状況の確認 ◆ 現在の設定値の確認 # sysctl -a | grep nf_conntrack net.netfilter.nf_conntrack_tcp_timeout_established = 432000 ← ①の対策 net.netfilter.nf_conntrack_max = 65536 ← ②の対策 net.nf_conn
NLBでfluentdのforwardパケットを分散させてみた - Qiita
AWSの新しいロードバランサであるNLB(Network Load Balancer)を使ってfluentdのforwardパケットを分散してみたので、レポートをまとめておく。 NLB自体については、クラスメソッドのブログ等で紹介されているのでそちらを参照するのが分かり易い。 静的なIPを持つロードバランサーNetwork Load Balancer（NLB）が発表されました！ 試してわかった NLB の細かいお作法 ざっくり言うと、TCPプロトコルを対象にしたALBって感じ。 ターゲットグループはポートレベルで設定できるので、コンテナ環境と相性が良い。 ポート違いで複数fluentdが立っていても同じグループとしてまとめて分散できる。 利用までの流れ ターゲットグループを作成し、TCPレベルでコネクションが貼れるかのヘルスチェックの設定をする インスタンスもしくは対象IPと、ポートの組を
AWSのネットワーク設計をサボらないでちゃんとやる
新規事業の立ち上げにAWSを選択する こういう状況はままあるでしょう。最安というわけではないけれど、将来どんな開発が必要になるか全く想像できない新規事業立ち上げフェーズにおいて、多種多様なPaaSを提供してくれるAWSはとても魅力的。 さて、いざ、EC2インスタンスを立ち上げてアプリケーションをデプロイするわけだが、みなさん、ちゃんとネットワーク設計していますか？まさかデフォルトVPCでサービス運営なんてしてないですよね？ というわけでネットワーク設計をして、VPCを設定していくわけだが、何を作ればよいか決まっている事業フェーズならともかく、新規事業立ち上げフェーズでは「将来どんな機能が必要になるかわからない」という前提でネットワーク設計をしておかなければいけない。そこで、「例えばこんな設計はどうでしょう」という提案をしてみる。 IPレンジ設計 まずはVPCとサブネットを使ってIPレンジを
RubyKaigi 2017 で Wi-Fi を吹いてきた #rubykaigi
2010 年から参加している RubyKaigi にとうとう 2017 ではスタッフとして参加してきた。今回は広島国際会議場で Wi-Fi を吹くという仕事をしてました。 https://rubykaigi.org/2017/ まず始めに、1 〜 2 日目の不安定さについて非常に申し訳なかった。だいたいわたしが悪いので悔しさしかない。ただ、3 日目は快調だったようでなによりでした。 本稿ではその裏側についてログを兼ねて書き残しておこうと思っています。 資料や設定集など GitHub repo Itamae レシピやネットワーク機器設定を置いておきますね。 https://github.com/sorah/rubykaigi2017-nw 今回から利用するドメイン名などを変数にくくりだしたりして他での使い回しがしやすくなっている…はず。 Grafana Public Snapshot 全体的
自律分散監視システムとそれを利用したネットワークグラフ可視化への挑戦 - Hatena Developer Blog
はじめに はてなサマーインターン2017の大規模システムコースの成果報告をします。 今年の大規模システムコースではメンターのid:masayoshiさんとid:y_uukiさんの下、自律分散監視システムとそれを利用したネットワークグラフの可視化に取り組みました。自律分散監視システムでは単純なクラスタリングによる死活状況の確認だけではなくアプリケーションレベルの疎通確認を行えるものを実現しました。またどのようにしてクラスタを形成するかという問題に取り組む内に、サービス間のネットワーク上のつながりを取得できるようになり、その情報でサーバー間の関係性の可視化を行いました。この記事では、それらの詳細を説明します。 はじめに 自律監視システムの実現 中央サーバー型の監視システム 自律分散監視システム アプリケーションレベルの相互監視 どうやってクラスタを形成するか？ 実験 ネットワークグラフの可視化
使うだけはもう飽きた! 自分でWebサーバーを書いてみよう! - Qiita
はじめに 今や様々なWebアプリケーションフレームワークが巷に溢れています。 いろいろ使ってみたけどしっくりこない。アプリケーションは簡単に作れるけどなんだか味気ない。 このエントリを読まれている皆さんはきっとそんな思いを抱かれているのではないでしょうか？ それなら、サーバーから自分で作っちゃいましょう！ Pythonを使いますが、簡単なのでPythonを書いたことがなくても平気ですよ。 それに、とっても楽しいです。 このエントリを読んでわかること Webサーバーの基本的な仕組み このエントリを読んでもわからないこと 実用に耐えうるWebサーバーの作り方 アウトライン 1.TCPでソケット通信してみよう 2.TCPサーバーを書き換えてWebサーバーを作ろう 3.マルチスレッド処理にする 1.TCPでソケット通信してみよう ご存知のとおりWebは主にHTTPというプロトコルで実現されています
2017年8月25日の大規模インターネット障害:Geekなぺーじ
先週の金曜日、Googleが誤った経路をインターネットに流したことによって、大規模な通信障害が発生しました。 大きな影響を受けたのが日本のOCNとKDDIだったとされていますが、様々な事業者が影響を受けたようです。 ネットワーク障害 グーグルが設定誤りで謝罪 グーグルが謝罪 大規模ネット障害、装置の誤操作が原因 ニュース解説 - 米グーグルの設定ミス、なぜ日本の大規模ネット障害を引き起こしたのか？：ITpro BGP leak causing Internet outages in Japan and beyond 8月25日に発生した大規模通信障害をまとめてみた 今回の障害は、世界中の組織とBGP(Border Gateway Protocol)で繋がっている巨大なネットワークを持つ「Googleだからこそ」の事例と言えそうです。 ここでは、その理由を紹介します。 ネットワークのネットワ
マルチホストでのDocker Container間通信 第2回 Port Forwarding と Overlay Network - Uzabase for Engineers
こんにちは。SPEEDA開発チームの鈴木です。 前回はマルチホストでのDocker Container間通信の説明の前段として、Dockerのネットワークが次のようになっているという話をしました。 今回はいよいよ、マルチホストでどうやってDocker Container同士の通信を実現するのかを説明していきます。 はじめに DockerによるContainerのマルチホスト間通信 Port Forwarding Overlay Network 1. Docker Swarm mode 2. 分散KVSとdocker network create -d overlayコマンドを使って自前で構築 3. flannelのようなOverlay Network構築ツールを使う Overlay Networkだけで解決できないこと シリーズ はじめに マルチホスト間でのDocker Container
ネットワーク入門サイト - 接続・速度・通信の基礎
基本編の概要 基本編は、家庭でインターネットを使う上でネットワークについて知りたいという人向けです。IPアドレスの設定やルーティングなど、基本的な項目について説明しています。 応用編の概要 応用編は、小中規模のネットワーク管理を任されて勉強しないといけないという人向けです。リンクアグリゲーション、スパニングツリーなど、管理者として必要な技術について説明しています。 設定編の概要 設定編は、ネットワーク機器の設定を行う人向けです。Catalystの設定を中心に、基礎から説明しています。 トラブル対応の概要 トラブルが発生した時、どのように切り分け対処するのかを説明しています。また、トラブル対応に必要な技術や、症状別トラブル対応についても紹介しています。 ネットワーク入門サイトについて 本サイトは、基礎とイメージ的な理解に主眼を置いた初心者向けのサイトです。本サイトを参照されて、少しでもネット
LinuxカーネルのTCPスタックとシステムコールの組み合わせによる手法よりも高速にポートのListenチェックを行う - 人間とウェブの未来
まずは前回の記事で盛大な誤認をしていたことを訂正しなければなりません。 hb.matsumoto-r.jp 前回の記事では、高速にリモートホストのポートチェックを3パケットで実現する実装を行うために、RAWソケットとユーザランドの簡易TCPスタックを実装してパケットを放出しましたが、カーネルのTCPスタックによって自動的にRSTパケットが返されるため、RSTパケットが返されるよりもはやくrecvfromしないとSYN+ACKを受け取れないと述べました。 しかし、以下のようにご指摘を頂き、 @matsumotory LinuxのSOCK_RAW+IPPROTO_TCPの場合、カーネルがRSTを送出したとしても同マシン上の既存raw socketに対するrecvfrom()が0を返すことはないと思うのですが、検証されているカーネルのバージョンはいくつでしょうか？— Hiroki Sato (@
高速にリモートホストのポートがListenしているかを調べる - 人間とウェブの未来
hb.matsumoto-r.jp 以下のエントリは一部誤認が含まれていたので、上記エントリにその旨をまとめましたので御覧ください。 とある事情でミドルウェア上から高速にリモートホストのポートのListenチェックをしたくなりました。ローカルホストのポートであれば、/procやnetlinkなどを使って素早くチェックする方法がありますが、今回は対象がリモートホストなのでソケットでなんとかする必要があります。 そこで、誰もがまず思いつくのは、connect()システムコールによってリモートホストのポートに接続しにいって、connectできればOK、できなければNGと判定する方法があり得るでしょう。（高負荷時に接続できないパターンはListenしていないと判定してよい） そこで一旦、最低限socket()システムコールとconnect()システムコールで接続する時のパケットをtcpdumpで眺
Cookpad TechConf 2017 提供 Wi-Fi の裏側 - クックパッド開発者ブログ
インフラ部 id:sora_h です。 先週開催された Cookpad TechConf 2017 如何でしたでしょうか。わたしは TechConf において Wi-Fi を担当していて、こちらも好評いただいたようでなによりでした。 というわけで、この記事では TechConf 2017 における Wi-Fi についての詳細を紹介します。 ネットワーク機器設定・サーバー mitamae レシピ等の公開 https://github.com/cookpad/techconf2017-network 今回の紹介する構成のうち、ネットワーク機器およびサーバ側の設定等、ほとんどを GitHub で公開しています。参考までにどうぞ。 TechConf 2017 NOC メンバー 実は外注などはしておらず、社内 IT と SRE グループのメンバーで構成されていました。 メイン (設計・運用・設営)
プログラマーが「ネットワーク怪しくない？」と思った時に覚えておくと便利なことまとめ - LIVESENSE ENGINEER BLOG
インフラエンジニアの中西です。 最近プログラマーからこのような話を耳にします。 「ネットワークって難しい/よくわからない」 最近ではAWS,GCPをはじめとするクラウドサービスが充実しているのでWeb界隈のエンジニアはなおさら気にするシーンが少なくなったように思います。 今日は最低限これだけ覚えていたら有事の際にちょっとは役に立ちますよという話が出来たらなと思います。 書式統一のため sudo を省略しています。ご容赦下さい。 コマンド編 ping ping です。疎通確認を行う時のコマンドです。 さすがに分かると聞こえてきそうですね。 例えば、192.168.1.1 というサーバに通信を確認したい場合はこうです。 $ ping 192.168.1.1 繋がる場合はこうなります。 $ ping 192.168.1.1 PING 192.168.1.1 (192.168.1.1): 56 d
ネットワークでなぜ遅延が生じるのか
5. プロセス遅延 (Processing Delay) パケット 出⼒先決定 ヘッダ書き換え フィルタリング QoS 統計情報取得 カプセル化 筐体内転送 • 伝送装置 • メディアコンバータ • スイッチ • ルータ • NAT装置 • 仮想化装置, IPsec, etc • 通信機器の⼊⼒インターフェイスで受信して 出⼒インターフェイスのキューへ送るまでにかかる時間 出⼒ キュー パケット ルータの例 暗号化 6. キューイング遅延 (Queueing Delay) • 通信機器の出⼒インターフェイスキューに⼊ってから 出⼒処理を⾏なうまでにかかる時間 出⼒キュー • 出⼒処理より速いペースでパケットが届くとキュー待ちが増える • 広帯域回線から狭帯域回線への転送、⼀時的な輻輳 (バーストト ラフィック) などへの対応 優先制御 キューイング スケジューリング 7. シリアル化遅延
次世代CDNのFastlyで即時削除(Instant Purge)を体感した | DevelopersIO
ども、大瀧です。 最近話題のCDN、Fastlyを触ってみました。そのセットアップレポートと、Fastlyの目玉機能の一つであるInstant Purge(即時削除)の様子をご紹介します。 Fastlyとは FastlyはFastly社が展開するCDN(Content Delivery Network)サービスです。最寄りでは東京と大阪にPOP(points of presence: CloudFrontで言うエッジロケーションのこと)があります。従来のCDNの型に収まらない様々なオプション機能を備え、Varnishを基盤技術とし設定をVCL(Varnish Configuration Language)で記述できるなど先進技術に特化したCDNと見ることができます。 価格体系は一般的なCDNとさほど変わりませんが、アカウント作成時に50ドル分までクレジットカード登録なしで試せる他、OSSデ
Best Speed Test Websites - November 2024 Reviews & Comparison
What are Speed Test Websites? Speed test websites and speed test apps are tools that enable individuals or IT professionals to test the speed of an internet connection on any device. Speed tests can measure upload speed, download speed, ping, latency, jitter, and more. Speed test websites can be used to test the internet speed of a WiFi or ethernet connection from a web browser on a desktop or lap
memcachedバイナリプロトコルは同期プロトコルを禁止するべき - Blog by Sadayuki Furuhashi
現状のmemcachedのバイナリプロトコルのクライアント（=libmemcached）は、リクエストの順番通りにレスポンスが返ってくることを期待しており、これはmemcachedバイナリプロトコルを「汎用的なkey-valueベースの分散ストレージのためのプロトコル」として考えると、ひどい実装である。 そのような実装は最適化の余地を大幅に制限してしまい、性能とスケーラビリティが悪化する。memcachedの仕様書は、そのようなクライアントの実装はバグであると明示するべきである。 現状のmemcachedクライアントの実装の問題点と、その解決策について述べる。 同期プロトコルと非同期プロトコル ネットワークプロトコルは以下の2つの種類に分けられる： 同期プロトコル リクエストの順番通りにレスポンスを返す（リクエストの順番とレスポンスの順番が同期している） 非同期プロトコル リクエストした順
djbdns (tinydns, dnscache) を使う | Netsphere Laboratories
（2003.11.03新規作成。2004.12.19 加筆。2004.12.31 更新。） djbdns (tinydns, dnscache) は、小さく、信頼性の高いDNS権威サーバ/キャッシュサーバです。bindのような複雑怪奇で脆弱なものは使うべきではありません。私は、LAN内の各機械のためのDNSキャッシュ、それぞれの機械の名前解決として使っています。 重要． (2014.12.12) ずいぶん昔から djbdnsは開発が止まっています。どのようなセキュリティ上の問題があるかないかも分からないので, もはや使うべきではありません。 権威サーバはNSD, キャッシュサーバはUnboundをおすすめします。DNSキャッシュサーバを選ぶ (2019.9) まさか, djbdns が再始動しました。N-DJBDNS. Fedora Linux にもパッケージが用意されています。 思想は健
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
知っているようで知らないWebサーバアーキテクチャ
