(Initial publication) |
(Update old link) |
||
| (6 intermediate revisions by 5 users not shown) | |||
| Line 1: | Line 1: | ||
The Fedora Infrastructure team has continuously planned and implemented measures to ensure that Fedora releases have a minimal (if any) '''impact on Red Hat's overall bandwidth'''. Unlike RHN, Fedora content is served to clients mainly through an extensive network of mirrors rather than through redhat.com internet properties. | |||
== Mirror Infrastructure == | == Mirror Infrastructure == | ||
| Line 10: | Line 10: | ||
http://fedoraproject.org/wiki/Infrastructure/Mirroring | http://fedoraproject.org/wiki/Infrastructure/Mirroring | ||
As of | As of August 2008, Fedora has over 200 active public mirrors. You can also find a list of our public mirrors at: | ||
http://mirrors.fedoraproject.org/publiclist | http://mirrors.fedoraproject.org/publiclist | ||
The only Red Hat run mirrors are at dl.fedoraproject.org and are in Phoenix, Tampa and Raleigh (see map below). For the releases we do not have these mirrors in our public list meaning users are directed entirely to non redhat mirrors to download Fedora. | |||
== Web Applications == | == Web Applications == | ||
Fedora hosts a number of user-facing websites and applications, but only some of these are served from Red Hat's PHX facility. A fraction of the mirror requests, and a fraction of the website requests, are served out of Red Hat equipment. Each request averages under 100K. This size is smaller than the average RPM package and therefore the impact on Red Hat, even during heavy traffic such as immediately following a release, tends to be negligible. | Fedora hosts a number of user-facing websites and applications, but only some of these are served from Red Hat's PHX facility. A fraction of the mirror requests, and a fraction of the website requests, are served out of Red Hat equipment. Each request averages under 100K. This size is smaller than the average RPM package and therefore the impact on Red Hat, even during heavy traffic such as immediately following a release, tends to be negligible. | ||
== Infrastructure Map == | |||
[[Image:ReleaseMap.png]] | |||
The above map shows our global network as it relates to releases. Of the web application traffic that hits RH only Phoenix is affected and even it only accounts for about 25% of the total web traffic. On the mirrors side none of these Red Hat listed (Phoenix, Tampa, Raleigh) mirrors show up in the public list on release day meaning no noticeable change in traffic should be seen on these servers. Additionally our entire torrent infrastructure exists on non-Red Hat servers. It's also important to note that Raleigh, NC, is internet 2 only traffic. | |||
== Client Downloads == | == Client Downloads == | ||
| Line 21: | Line 29: | ||
=== Via BitTorrent === | === Via BitTorrent === | ||
When clients make download requests via BitTorrent, they retrieve a small (320K) metadata file that gives them the information needed to retrieve the ISO image files for CD or DVD distribution media via p2p file sharing. After a very small number of initial downloads, this method allows the vast majority of download bandwidth to be moved away from any Fedora infrastructure or even downstream mirrors. Red Hat provides almost no bandwidth for these requests. | When clients make download requests via BitTorrent, they retrieve a small (320K) metadata file that gives them the information needed to retrieve the ISO image files for CD or DVD distribution media via p2p file sharing. After a very small number of initial downloads, this method allows the vast majority of download bandwidth to be moved away from any Fedora infrastructure or even downstream mirrors. Red Hat provides almost no bandwidth for these requests. All of these requests are served out of ibiblio on non-redhat infrastructure. | ||
The Fedora torrent servers track the data they have provided here: | The Fedora torrent servers track the data they have provided here: | ||
http://torrent.fedoraproject.org:6969/ | http://torrent.fedoraproject.org:6969/ | ||
Since its release in May 2008, this system has allowed us to serve | Since its release in May 2008, this system has allowed us to serve almost 1 petabyte of Fedora 9 distributions alone to the community. | ||
=== Via Direct Download === | === Via Direct Download === | ||
| Line 36: | Line 44: | ||
== Other Concerns == | == Other Concerns == | ||
Fedora normally releases a distribution twice a year -- once near May 1st, and again near October 31st (i.e. May Day and Halloween). However, in the event of schedule slippage, the distribution methods described above should prevent any excess bandwidth costs to Red Hat while still giving full control over the Fedora release schedule to the community, where it belongs. | Fedora normally releases a distribution twice a year -- once near May 1st, and again near October 31st (i.e. May Day and Halloween). However, in the event of schedule slippage, the distribution methods described above should prevent any excess bandwidth costs to Red Hat while still giving full control over the Fedora release schedule to the community, where it belongs. The current release schedule is always found on the [[Schedule]] page. | ||
[[Category:Infrastructure]] | |||
Latest revision as of 17:22, 31 January 2012
The Fedora Infrastructure team has continuously planned and implemented measures to ensure that Fedora releases have a minimal (if any) impact on Red Hat's overall bandwidth. Unlike RHN, Fedora content is served to clients mainly through an extensive network of mirrors rather than through redhat.com internet properties.
Mirror Infrastructure
Fedora has a system of mirrors made up of several tiers of hosts which carry our content throughout the globe. The first tier, which takes its content directly from Red Hat, is limited in size and contains many Internet2-connected hosts. Hosts in the second tier take their content from the first tier, and so on.
We provide 100% open source mirror management software that makes it easy for mirrors to retrieve copies of the entire set of Fedora content. This is markedly different from Red Hat Network (RHN), which is a single source for customer data.
Mirrors carry not only our base distribution as it appears on release day, but also our updates over the course of a release's lifecycle. More information about Fedora's extensive mirror system is available at: http://fedoraproject.org/wiki/Infrastructure/Mirroring
As of August 2008, Fedora has over 200 active public mirrors. You can also find a list of our public mirrors at: http://mirrors.fedoraproject.org/publiclist
The only Red Hat run mirrors are at dl.fedoraproject.org and are in Phoenix, Tampa and Raleigh (see map below). For the releases we do not have these mirrors in our public list meaning users are directed entirely to non redhat mirrors to download Fedora.
Web Applications
Fedora hosts a number of user-facing websites and applications, but only some of these are served from Red Hat's PHX facility. A fraction of the mirror requests, and a fraction of the website requests, are served out of Red Hat equipment. Each request averages under 100K. This size is smaller than the average RPM package and therefore the impact on Red Hat, even during heavy traffic such as immediately following a release, tends to be negligible.
Infrastructure Map
The above map shows our global network as it relates to releases. Of the web application traffic that hits RH only Phoenix is affected and even it only accounts for about 25% of the total web traffic. On the mirrors side none of these Red Hat listed (Phoenix, Tampa, Raleigh) mirrors show up in the public list on release day meaning no noticeable change in traffic should be seen on these servers. Additionally our entire torrent infrastructure exists on non-Red Hat servers. It's also important to note that Raleigh, NC, is internet 2 only traffic.
Client Downloads
Via BitTorrent
When clients make download requests via BitTorrent, they retrieve a small (320K) metadata file that gives them the information needed to retrieve the ISO image files for CD or DVD distribution media via p2p file sharing. After a very small number of initial downloads, this method allows the vast majority of download bandwidth to be moved away from any Fedora infrastructure or even downstream mirrors. Red Hat provides almost no bandwidth for these requests. All of these requests are served out of ibiblio on non-redhat infrastructure.
The Fedora torrent servers track the data they have provided here: http://torrent.fedoraproject.org:6969/
Since its release in May 2008, this system has allowed us to serve almost 1 petabyte of Fedora 9 distributions alone to the community.
Via Direct Download
Clients are directed via Fedora's main web site to a proxy host that diverts requests to a mirror site. In most cases we attempt to divert to geographically proximate hosts, to improve speed for the client. Red Hat provides almost no bandwidth for these requests.
Since its release in May 2008, this system as allowed us to serve nearly 750,000 copies of Fedora 9 to the community -- over 160,000 in just its first week of release.
Other Concerns
Fedora normally releases a distribution twice a year -- once near May 1st, and again near October 31st (i.e. May Day and Halloween). However, in the event of schedule slippage, the distribution methods described above should prevent any excess bandwidth costs to Red Hat while still giving full control over the Fedora release schedule to the community, where it belongs. The current release schedule is always found on the Schedule page.