コンテナ型とハイパバイザ型の仮想化 NW分離覚書き - Qiita
遅ればせながら、コンテナ型仮想化ツール「Docker」を検証環境で利活用はじめました。 なにぶん自分はNWエンジニアなので、Dockerをはじめとする「コンテナ型仮想化」ツールについて まず何より最初に、そのNW分離方法の特徴に興味をそそられました。 そこで、これまで多用してきたlibvirt + KVMによる「ハイパバイザ型仮想化」とのLinux内部的な NW分離の実現方式の比較を、覚書きとして残したいと思います。 「コンテナ型仮想化」（Docker）のNW分離について まずDockerがホストとコンテナのNWをnamespaceモジュールの機能によって実現している事を 確認します。 root@ubuntu:~# ps -ef | grep docker root 1219 1 0 Sep11 ? 00:01:53 /usr/bin/docker -d root 21478 9790 0
Ethernetの受信処理
2. rcu read lock receive_queue lock nf_hooks nf_iterate rcu read lock tcp_rcv_established tcp_v4_do_rcv nf_hook_slow nf_hook_thresh ___napi_schedule __napi_schedule e1000_intr handle_irq do_IRQ common_interrupt interrupt get_rps_cpu sock_queue_rcv_skb ip_queue_rcv_skb __udp_queue_rcv_skb udp_queue_rcv_skb __udp4_lib_rcv ip_local_deliver_finish NF_HOOK ip_defrag ip_rcv_finish NF_HOOK ip_rcv __netif
LinuxでのNIC冗長化(bonding)を少し深く考えてみる - sanonosa システム管理コラム集
サーバNIC(Network Interface Card)の可用性向上や負荷分散にはNIC冗長化が有効です。NIC冗長化については拙著「インフラエンジニアの教科書」にも記しましたが、bonding、チーミング、リンクアグリゲーションなど様々な呼び名があります。今回はLinux上でのNIC冗長化の話しとなりますので、bondingについての話題となります。 【bondingとは】 bondingとは、複数のNICが搭載されているマシンのNICを束ねて1つの仮想的なNICとして扱うことのできる技術です。例えば1GbpsのNICポートが4つ搭載されているサーバとL2スイッチの間を4本のLANケーブルで接続してbonding設定を有効にさせると、冗長化が行われて最低1本が正常であれば1～3本に問題があっても通信が継続できたり、負荷分散が行われて通信帯域幅を4Gbpsに拡張されたりといった使い方が
DMM inside
日本アニメ初の快挙！海外アニメ賞を受賞した『スキップとローファー』海外ライセンス部長&プロデューサーが語る、奮闘の舞台裏
DMM inside
日本アニメ初の快挙！海外アニメ賞を受賞した『スキップとローファー』海外ライセンス部長&プロデューサーが語る、奮闘の舞台裏
RHEL7のNICのネーミングルール - めもめも
参考資料 ・Predictable Network Interface Names 何の話かというと RHEL7では、NICのネーミングルールが変わっています。RHEL6では、DELL製のハードウェアの場合だけネーミングルールが変わるという謎のudevルール（biosdevname）がありましたが、RHEL7では、さらにまた仕組みが変わって、systemdがNICのネーミングを行うようになりました。 まとめると次のようになります。 バージョン ハードウェア ネーミングルール RHEL5 すべて 古典的な「eth0」「eth1」など RHEL6 一般のマシン 古典的な「eth0」「eth1」など RHEL6 DELL製のハードウェア biosdevnameによる「em1」「em2」「p1p1」など RHEL7 一般のマシン Predictable Network Interface Name
TCP incast: What is it? How can it affect Erlang applications? | Humans and Hippos in Harmony
So, what’s the deal with the “TCP incast” pattern? Never heard of it? Join the club. I’ve been wearing a developer hat for too long and not wearing my sysadmin and network manager hats. And the publications about Ethernet microbursts and the TCP incast pattern have been hiding in conference proceedings & journals that I don’t follow. (Note to self: change reading habits.) If you’d rather read
Dive into dockerネットワーク
7. DockerのNetworking ● 確認してみよう！ ● $ ip a ● ifconfigとか使ってるのはおっさんらしいです ＞＜ ● http://opcdiary.net/?p=28500 ● RHEL7ではsystem-config-networkは廃止、 ifconfigやrouteなどのnet-toolsが非推奨 8. $ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 2: eth0: <BROA
クラウドインフラを支える高性能ネットワーク、ストレージ技術
カテゴリー DX (2) 一般 (58) 研究会 (6) 働き方 (4) 技術 (349) Edge AI (2) Edge Computing (12) Erlang (1) FIWARE (2) Fog Computing (9) Infiniband (31) Internet of Things (32) Key Value Store (17) Linux (3) Linux KVM (10) Machine Learning (2) RealTime Web (14) Webサービス (42) インフラ (7) コンテナ (3) ストレージ (92) データセンター (7) データベース (47) データ流通 (6) テレプレゼンス (2) ネットワーク (214) 仮想化 (110) 災害コミュニケーション (26) 空間情報 (30) 量子コンピューティング (3) 教育
バックログの指定 - 揮発性のメモ２
listenのバックログが指定できない - 揮発性のメモの続き http://www.linux.or.jp/JM/html/LDP_man-pages/man2/listen.2.html int listen(int sockfd, int backlog); backlogでバックログの数＝accept()待ちの接続のキューの数を指定できる。 ということになっているけど、実際はキューの数をあまり制限できないっぽい。 カーネル側の設定を # cat /proc/sys/net/ipv4/tcp_syncookies 0 # cat /proc/sys/net/ipv4/tcp_max_syn_backlog 1プログラム側を result = listen( sd, 1 );として制限かけていても、実際にはセッションが確立してしまう。 tcp 0 0 172.16.1.4:5000 1
柔軟な IT インフラとそれを支える技術 | GREE Engineering
こんにちは、インフラストラクチャ本部の大山裕泰です。最近話題の WhiteBox スイッチと、そのミドルウェアについてお話したいと思います。 柔軟な IT インフラを目指して 我々に限らず IT インフラに携わるエンジニアにとって、アプリケーションレイヤの人たちが望むアプリケーション実行環境の構築・運用は主要な目標の一つかと思います。 アプリケーション実行環境の形態は様々ですが、突き詰めてゆくと物理的なネットワーク機器に Ethernet ケーブルで接続された物理サーバの集合になります。やや管理的な話になりますが、こうした物理機器は減価償却してゆくので、これが終了するあるいはサポートが切れるまでの 4～5 年の期間、同じ機器を使い続けることになりますので、機器の選定においては長い目で見る必要があります。 これに対して、アプリケーションやアプリケーションを取り巻く環境は日々目まぐるしい速度で
joeloughton.com - このウェブサイトは販売用です！ - joeloughton リソースおよび情報
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
NUMAアーキテクチャとネットワーク性能（１）－説明編 - Blog
NUMA(Non-Uniform Memory Access)とは Non-uniform memory access - Wikipedia, the free encyclopedia NUMA - Wikipedia NUMA（Non-Uniform Memory Access、ヌマ）とは、共有メモリ型マルチプロセッサコンピュータシステムのアーキテクチャのひとつで、複数プロセッサが共有するメインメモリへのアクセスコストが、メモリ領域とプロセッサに依存して均一でないアーキテクチャである。 複数CPUがある場合、近いメモリと遠いメモリが構成上存在し、データが置かれる場所によって、性能に差が出てしまうアーキテクチャである。 ネットワーク性能を測定する場合も、NUMA構成上不利な状態で性能測定をしてしまうと、思うような性能が出ない場合があるため、注意が必要である。本稿では、NUMA及びCPU
スイッチ・ルータのしくみ
最終更新は2013.7.14です．以下でLTした資料に加筆しました． ・カーネル/VM�探検隊@TKB 2012.9.22 ・自宅ラック勉強会 2012.10.8
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ZettioがDocker用ネットワークシステムのWeaveをリリース
Using Docker in Cloud Networks
Wireshark だけに頼らない! パケット解析ツールの紹介
インフラエンジニアのための次世代プロトコル入門 -
July TechFesta 2014
YAPC::Asia2014会場ネットワークのツクリカタ - YAPC::Asia Tokyo 2014
登 大遊
