September 2005 - Ris-int - mailman.ripe.net

RIS status report at RIPE51
by arife＠ripe.net 28 Sep '05

28 Sep '05

Hi guys, There will be 5-10 mins status update at Routing-WG, RIPE51. Presentation will roughly contain the following main points: - RIS: What is it? Contact info - Stats (if we can find some interesting stats) - RIS Performance study - Central server trouble keeping up with RRC - Analysis check for memory, CPU, and disk I/O - Result, disk is bottleneck - Solution: add disks -> even better, split DBs across servers - Getting away from central server design - Add more CPU and Disk. - What are user needs? - Fast applications - Less time lag - More data in DB - Feedback from users. Please let me know if something is missing. -- Arife Vural SED, RIPE NCC

1 0

impetus Pfharmaceutical
by Elijah Bourquin 27 Sep '05

27 Sep '05

Sav % On your Med harmacyByM e up to 70 ications today with P ail XanaViagCialVali xraisum $1 $3 $1 $3 42.33.21.75 and many s in our s other medication hop - http://www.jne-medds.chatpusher.com

1 0

riswhois request: reporting parent routes (fwd)
by Rene Wilhelm 08 Sep '05

08 Sep '05

Hi, Though it's nice to have an active user providing suggestions, I have the feeling his latest request would fall in the category "feature creep", making the program larger, more complex and the output harder to understand. However, before sending him a polite no-no, I'd like to ask how others in RIS feel about this. Should RISwhois embark on the trail of cross examining other routes (parents, daughters, siblings, ...) or not? -- Rene ---------- Forwarded message ---------- Message-ID: <431C426B.1060807(a)priv.onet.pl> From: Andrzej Adam Filip <anfi(a)poczta.onet.pl> Sender: ris-users-admin(a)ripe.net To: ris-users(a)ripe.net Date: Mon, 05 Sep 2005 15:04:43 +0200 Subject: riswhois: reporting parent routes Could riswhois generate statistics of "parent routes" for given route? [ parent, not ancestor] My goal is achieve better coverage of IP->AS mappings based on riswhois provided data. Unanimous AS reports (after ignoring default route) give very good starting point I would like to extend. For 65.54.160.0/19 I would like to know how many of 58 rispeers reporting the route reports also 65.52.0.0/14 route as belonging to AS8070. e.g. route: 65.54.160.0/19 origin: AS12076 [...] num-rispeers: 58 numrp-parent: 58 65.54.160.0/19 AS8070 P.S. As security precaution riwhois may limit number of parent routes reported to e.g. <10 ---------------------------------------------------------- $whois -h riswhois.ripe.net -- 65.54.162.200 [leading comments and default route entry skipped] route: 65.52.0.0/14 origin: AS8070 descr: MICROSOFT-CORP---MSN-AS-BLOCK - Microsoft Corp lastupd-frst: 2005-07-21 08:28Z 202.12.28.190@rrc00 lastupd-last: 2005-09-05 07:49Z 193.111.172.55@rrc03 seen-at: rrc00,rrc01,rrc03,rrc04,rrc05,rrc06,rrc07,rrc10,rrc11,rrc12,rrc13,rrc14 num-rispeers: 58 source: RISWHOIS route: 65.54.160.0/19 origin: AS12076 descr: HOTMAIL-AS - Hotmail Corporation lastupd-frst: 2005-06-29 08:05Z 195.66.224.151@rrc01 lastupd-last: 2005-09-05 07:49Z 193.111.172.55@rrc03 seen-at: rrc00,rrc01,rrc03,rrc04,rrc05,rrc06,rrc07,rrc10,rrc11,rrc12,rrc13,rrc14 num-rispeers: 58 source: RISWHOIS ---------------------------------------------------------- -- Andrzej [en:Andrew] Adam Filip anfi(a)priv.onet.pl anfi(a)xl.wp.pl All that is necessary for the triumph of evil is that good men do nothing -- Edmund Burke (1729-1797)

3 4

Re: [ris-int] Re: [Fwd: backup bottlenecks and possible improvements]
by Gerard Leurs 08 Sep '05

08 Sep '05

Daniel. > It appears that particular equipment (netapps filer), which is easy to > operate, becomes too expensive. > it might be a good idea to invest a > little ops time in a cheap storage boxes for stuff that does not need > filer-quality storage. I'll keep it short: For over one year we have cheap IDE disks in an EMC-CX300. And our F810c (=NetApp at singel258) is no longer in use as backup-medium. Gerard.

4 3

Re: [ris-int] riswhois request: reporting parent routes (fwd)
by Rene Wilhelm 07 Sep '05

07 Sep '05

> I do not understand the question fully but > I would point him to the RIS itself. If this is a general question > we could do a specialised query to the RIS for it. > But not complicate riswhois. Small is beautiful. Right, that's also what I had in mind; RISwhois provides a first quick overview, an overal looking glass on various RRC bgp tables. More complex queries, analysing updates, combining data from different prefixes, are out of scope, should be answered from RIS DB. -- Rene

1 0

Re: [Fwd: backup bottlenecks and possible improvements]
by Gerard Leurs 07 Sep '05

07 Sep '05

Dear all.. > > space. A comparison tells me that if we convert from gzip to bzip2, we > > would save something like 25% of the space. This is only 100 Gbyte or > > so, but nice to have. Nice idea, but saving only 100GB is not much on a 1.6TB filesystem. And it is not a real solution to the diskspace-problem I was talking about. One extra concern: if you do so we will have 300GB of gzipped files on the backupserver, and 200GB of bzipped2 files. And as a result we do not have any space anymore on the backupserver. And that is exactly what I/ops is trying to solve. Pls do not do this on your own and consult ops before actually planning this! Gerard.

4 4

Re: [Fwd: backup bottlenecks and possible improvements]
by arife＠ripe.net 06 Sep '05

06 Sep '05

> It looks like we are backing up the correct data for RIS. It is only the > "raw data". > > I had a quick look at the raw data, and I think we can save a *lot* of > space. A comparison tells me that if we convert from gzip to bzip2, we > would save something like 25% of the space. This is only 100 Gbyte or > so, but nice to have. I think it's a good idea. We can convert from gzip to bzip2. Few applications that use rawdata need to be changed to use bzip2. If you agree to use bzip2, I can proceed, and do the change. I guess we need to announce our users. Arife > > In fact, perhaps more generally we should look at our various compressed > files and convert from gzip to bzip2. We already did this for the Whois > database logs a few years ago, and saw a large savings. > > Andrei Robachevsky wrote: > > >Shane, > > > >FYI. This may help in the RIS backup design. > > > >Andrei > > > >-------- Original Message -------- > >Subject: backup bottlenecks and possible improvements > >Date: Tue, 9 Aug 2005 16:23:59 +0200 (CEST) > >From: gerard(a)ripe.net (Gerard Leurs) > >To: andrei(a)ripe.net, gerard(a)ripe.net, ruud(a)ripe.net > > > >Andrei + Ruud. > > > >I promised to write something about our current backup. > > > >Pls have a read, and when there are questions/suggestions > >I'm happy to answer them. > > > > Gerard. > > > > > >++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >Backup system. > > > >Short description. > > > >We backup (or rather synchronise) unique filesystems from servers > >on a frequent basis to a huge EMC diskvolume. > >At least twice a day, but for some servers-filesystems up to every > >half hour. > > > >We keep the backups for a period, so we can restore from online-backup. > >The retentionperiod depends a little bit on the server, but in general > >we have snapshots for the last 14 days + 1 week + 1 month. This provides > >for 'online' restoring files of the last 7 weeks. > > > >This strategy proves to be sufficient for almost all cases we have > >wrt restoring files, or installing and synchronisation of a replacement > >server. > > > >When we purchased our current hardware we already anticipated possible > >future growth. And possible addition of servers and services. > > > > > >Current status. > > > >Although we reduced the amount of snapshots to keep drastically we > >do not gain lots of diskspace. Most data on any filesystem does not > >change over time. And only the changed data requires extra diskspace > >on our backupserver. > > > >There is still enough EMC-diskspace for the serverbackup. > >We can even add some new servers, without hassle. > >But for the filer backups it is getting awkward. > > > > size used available > >emc1 (serverbackup) 1.6 TB 1.4 TB 247 GB > >emc2 (filers + RIS + DNSMon) 1.6 TB 1.5 TB 184 GB > > > > > >We did not anticipate that the diskusage for the former NP-services > >would have such an enormous impact on the EMC. Approx. 1 GB is solely > >taken by the full backup for RIS, TTM and dnsmon. > > > >Some rough estimates of diskusage are: > >For EMC2: > >- filer2 189 GB > > 80 GB homedirs > > 46 GB groupdirs > > 32 GB roledirs > > 21 GB ticketDB > >- filer3 183 GB > > 95 GB datadirs > > 39 GB web dirs > > 12 GB FTP dirs > >- weesp > > 236, 111, 2 GB for RIS > >- dolphin > > 94, 102 GB for dnsmon > > > >For EMC1: > >- ceiba > > 34, 34, 34, 33, 11, 132 GB, all for TTM data > >- too many other servers to report > > > > > >Future plans (2006). > > > >- Replacing our current filers with more powerfull filer, with more > > diskspac, increases demands for diskspace. > >- Adding services on the TTM-cloud, and collecting this data on a > > central server, also requires extra diskspace. > >- Adding backup of laptops also requires extra diskspace. > >- "Natural growth" of diskusage requires extra diskspace. > > > > > >How can we be pro-active for possible diskspace problems? > > > >- Reduce amount of snapshots to the absolute minimum. > > This will however not free half of the current EMC-diskspace. > > But possibly only 10%. > > And the number of snapshots is not that high anymore. > > I think not the option, which solves our diskgreed for years. > > > >- Change backup strategy. > > + Expire all files older than 1 year. And do not sync them onto the > > EMC. > > pro: saves diskspace > > con: hard and time-consuming to restore a filesystem/server > > from backups > > hard to implement > > will ot save time for the sync-operation > > admin. overhead increased by factors > > I would not consider this a good option. > > > > + Staff removes files older than x months/years. > > pro: saves diskspace > > con: time consuming for everyone > > hard to convince everyone > > will not work for dirs of websites, ftpsite, > > ticketDB and lots of other dirs. > > I would not consider this a good option. > > > > + Do not add new servers, filesystems and laptops to the backup > > Obviously one of the worst options possible. > > > >- Buy an expansion diskarray, similar to the current diskarray. > > This gives us 3 TB of extra diskspace. > > pro: no administrative workload > > no reduced quality of service > > get dedicated EMC-filesystem for filers > > be able to backup the new filers (larger diskspace) > > anticipated for additional data of services on TBs > > possibility to add more filesystems, and servers to backup > > con: invest 17.150 euro > > spend time on configuration (and on data-migration) > > > >++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > > -- Arife Vural SED, RIPE NCC

3 3