Jan,<br>
<br>
Great! I can only image that your very busy, however, do you have any sort of time frame for this to be commited to CVS?<br>
<br>
Regards,<br>
Paul<br><br><div><span class="gmail_quote">On 5/30/05, <b class="gmail_sendername">Jan Janak</b> <<a href="mailto:jan@iptel.org">jan@iptel.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 30-05-2005 14:11, Greger V. Teigre wrote:<br>> See inline.<br>> Jiri Kuthan wrote:<br>> >At 09:24 AM 5/30/2005, Greger V. Teigre wrote:<br>> ><br>> >[...]<br>> >>>* when ser starts up usrloc is "lazy-loaded"
<br>> >>>* if a usrloc record is looked up in cache and is __NOT__ found,<br>> >>>then MySQL will be queried. If found in MySQL then the usrloc<br>> >>>record will be put in to cache for future lookups
<br>> >>><br>> >>>By doing these two things we should not have a problem we<br>> >>>excessively large subscriber bases.<br>> >>><br>> >>>Thoughts?<br>> >>
<br>> >>Makes sense. This is how Berkeley DB and many other DBs work. In<br>> >>fact, the best would be to build an abstraction cache layer around<br>> >>all the query functions that have data in the DB. This way you would
<br>> >>get the optimum performance/scalability.<br>> ><br>> >I have to admit I am not sufficiently familiarized with BDB. If I<br>> >understand it right, they do confgurable in-memory caching and they
<br>> >also support some kind of master-slave replication. I am not sure<br>> >though how this scales...(20 SERs with 20 BDBs, one of them master<br>> >and replicating UsrLoc changes to 19 slaves who are all able to
<br>> >identify inconsistent cache?)<br>> ><br>> >I mean the structural problem here is dealing with r-w intensive<br>> >Usrloc operations and still desiring to replicate for reliability.<br>> >There is a variety of algorithms to deal with it and I don't know
<br>> >well what the respective DB systems actually do.<br>><br>> I'm not proposing to use BDB, it was just an example. Databases are very<br>> good at replication, even two-way replication can be done quite efficiently
<br>> through locking etc. I just took Paul's setup with cluster back-end as<br>> granted and wrote my comments based on that...<br>><br>> Thinking a bit wider and building on your comments, Jiri:<br>> The challenge, I think, is to handle the following things in any likely
<br>> deployment scenario:<br>> 1. Usrloc writes to cache vs. DB<br>> 2. Replication of usrloc, multiple DBs vs. cluster, across LAN or WAN<br>> 3. Memory caching management (inconsistencies etc)<br>><br>> For the sake of the readers, here is how I understand SER's operations
<br>> today:<br>> 1. Usrloc is always written to cache, DB write is controlled through<br>> write-through parameter<br>> 2. Replication is handled by t_replicate<br>> 3. Management of cache is not needed, the cache is always updated. However,
<br>> an updated DB (and thus dirty cache) will not be detected<br><br> I am working on that already. The entries in the usrloc cache will<br> have an additional expires value and if that value expires then the<br> usrloc code will refresh it from the database. Also there will be no
<br> full cache anymore -- usrloc will cache only a portion of the whole<br> location database and old entries will be using LRU scheme.<br><br> The cache will be empty upon startup. When SER calls lookup then<br> usrloc will search the cache -- if there is no entry or if it is
<br> expired then it will load it from the database and store in the cache<br> for limited period of time. If there is no entry in the database then<br> it will create a negative cache entry (to limit the amount of<br>
unsuccessful database queries).<br><br> Database updates will not assume anything about the state of the<br> database so it should not matter if the entry still exists / does not<br> exists / has been modified..<br><br>
There is one drawback though -- nathelper as it is implemented right<br> now will not work anymore -- we would need to rewrite it to use the<br> contents of the database.<br><br>> Here is how I understand Paul's proposal (and with my annotated suggestions
<br>> from my last email :-):<br>> 1. Usrloc is always written to DB, cache is updated if it is already in the<br>> cache<br>> 2. Replication is handled by underlying database across DBs or in a cluster<br>> 3. If usrloc is not found, DB is checked. If cache is full, some mechanism
<br>> for throwing out a usrloc is devised<br>><br>> I must admit I often fall for the argument: "let each system do what it is<br>> best at."<br>> Following that, replication should only be done at an application level if
<br>> the underlying database is not capable of doing it (if we agree that a DB<br>> is good at replication). The only thing I see a DB is not capable of, is<br>> handling the NAT issues. So, if a given usrloc has to be represented by
<br>> different location (ex. the registration server), then the DB cannot do<br>> replication. However, if the NAT issue is handled through some other means,<br>> ex. Call-Id aware LVS with one public IP, then the usrloc should be the
<br>> same across DBs and the DB should handle the replication.<br><br> Another approach would be to let the user agent handle NATs. Sipura<br> phones, for example, can register with two proxy servers.<br><br>> You don't need many subscribers before you'll want redundancy and as
<br>> active-passive redundancy is a waste of resources, I believe an upgrade of<br>> the replication mechanism should soon be imminent. ;-)<br>> I think I have said this before, but this is my enterprise-level "dream"
<br>> scenario:<br>> 1. Two geographically distributed server centers<br>> 2. DNS SRV for load distribution (and possible using segmentation of<br>> clients through their configurations if they don't support DNS SRV)
<br>> 3. Each data center has Call-Id sensitive LVS in front, with one or more<br>> servers at the back (a fair-sized LVS box can handle 8,000 UDP packets per<br>> second)<br>> 4. Each data center either has a DB cluster or two-ways SER-based
<br>> replication<br>> 5. The data centers replicate between each other using either DB-based<br>> replication or two-ways SER-based replication<br>> 6. The SER-based replication is an enhanced version of t_replicate() were
<br>> replication is to a set of servers and replication is ACKed and guaranteed<br>> (queue). I would suggest using the XMLRPC interface Jan has introduced<br>> 7. I think Paul's cache-suggestions are good regardless of decisions on
<br>> replication<br>><br>> Entry level scenario where the same box is running LVS, SER, and DB (you<br>> can quickly add new boxes) has a very low cost.<br>><br>> >> However, there is one more thing: You need to decide on an
<br>> >>algorithm for selecting a usrloc record to replace when the cache is<br>> >>full. Do you store extra info in memory for each usrloc to make the<br>> >>right decision (ex. based on the number of lookups).
<br>> ><br>> >You may also purchase more memory :)<br>><br>> Do you suggest that no mechanism should be devised when the cache limit is<br>> hit? ;-) Then maybe I can suggest an email alert to the operator when a
<br>> certain amount of the cache is full... :-D I trust my people to act fast<br>> and appropriate, but not that fast and appropriate!<br>><br>> g-)<br>><br>> _______________________________________________
<br>> Serusers mailing list<br>> <a href="mailto:serusers@lists.iptel.org">serusers@lists.iptel.org</a><br>> <a href="http://lists.iptel.org/mailman/listinfo/serusers">http://lists.iptel.org/mailman/listinfo/serusers</a><br></blockquote>
</div><br>