UPDATE: This English translation was produced by ChatGPT on 2025-05-17 from the original blog post dated 2006-06-24. The original Czech version appears below the translation.
We often talk about a “working application,” but today’s applications—or more precisely, software systems—are no longer as simple as single-user DOS applications once were. Today, we expect software systems to handle a high number of transactions per second, support hundreds or ideally thousands of users, and be multi-tiered and integrated from multiple interconnected subsystems using the best integration tools. This makes them scalable and robust. You may have heard these terms before, but who can really make sense of it all? You practically need a team of experts to run such a system.
Who exactly do you need? A software architect, analyst, developer, operating system administrator, database administrator, and network administrator. Great—but now you’re facing monthly costs so high that you’ll need a really solid business plan to cover the overhead of all these people and still make a profit. But even if you’re lucky enough to have such a team, are they capable of quickly and reliably identifying every operational issue in the system?
Let me illustrate with a specific case that detecting a malfunction in a software system is not always straightforward. For years, we have been developing and operating an online airline ticket reservation system for a customer. The system is divided into several mutually communicating layers. The layer closest to the customer (let’s call it Layer 1) is a classic web system that uses object-oriented techniques (inheritance) to extend a simpler web layer (Layer 2). Layer 2 contains all the logic for the user interface but not the full visual appearance, text, or other customizations—that's all handled by Layer 1. This setup is ideal, especially since there are many customized websites built on the same foundation.
Both of these layers provide only the graphical user interface, while the reservation logic itself resides on the application server (Layer 3). Layer 2 communicates with Layer 3 using XML over TCP/IP. Layer 3 simulates the work of a live travel operator and attempts to find optimal flight connections in the AMADEUS international reservation system based on user requests. Layer 3 communicates with AMADEUS via its proprietary API over TCP/IP. It also has to store certain information and uses a database server for this, also connected via TCP/IP.
You’ll agree that this can no longer be considered a simple software system. From a hardware perspective, at least three servers are used: one web server for Layers 1 and 2, one application server for Layer 3, and one database server. All of them must be connected via a network. And this doesn’t even include the AMADEUS servers located on the other side of the globe, or additional servers used for load balancing, backups, automatic email notifications, DNS servers, and so on.
I’ve described this “relatively simple” system just to show how difficult it can be to diagnose a suddenly appearing issue. We had been developing and maintaining the software for about five years, while a third party was responsible for its operation. About a year ago, after a period of dissatisfaction, the customer decided to end the cooperation with the third-party provider and asked us to take over system operations as well.
Anyone who has ever taken over an existing information system knows that it’s no walk in the park. For us as developers, it was a bit easier because we understood the system architecture, but even so, some "improvements" had been made on the production servers during operations, and no one really knew much about them. Fortunately, we were able to arrange a gradual handover of the servers and document those “enhancements” with the former operator.
I won’t hide the fact that the server transition has been going on for nine months already, but since the system works, there was no rush. The transition involves preparing new hardware and reinstalling everything from scratch—while also upgrading hardware, the OS, and required libraries.
Now we’re getting to the core of the story. At one point, the web and application servers were still in the old provider’s data center, while the database server had already been successfully moved to our own. The system operated in this setup for several weeks without issues.
Then the client called, complaining that the web reservation system was occasionally not working. After further diagnostics, we found that sometimes the system worked fine, sometimes it was slow, and sometimes it didn’t work at all. Log files showed issues between the application server (Layer 3) and the database server. The application server logs had many errors about failed database connections.
I started reviewing what had changed in the hours and days leading up to the incident. The day before, we had deployed a new version of the application server, but the changes were minor and should not have affected the database connection. Still, I reverted to the older version just in case—but that didn’t help.
So I focused on the database. Its logs showed numerous failed connection attempts from the application server. After too many failures, the database blocked further access from that source. I then tried modifying some configuration parameters—increasing the number of allowed connections, increasing the client connection timeout, and so on. After about two hours of trying everything, there was still no improvement.
Then I remembered an email from our ISP a week earlier, warning of a 5-minute outage scheduled at 5:00 AM. I immediately checked my inbox and confirmed that the outage did occur that very day—and it matched exactly with the first connection errors in the application server logs.
We had acknowledged the email at the time, but our systems typically handle such short outages gracefully. Our central monitoring also reported no issues. But you’ve probably guessed it: since the application and database servers were in different data centers (with different ISPs), it turned out to be a network problem.
I launched a more aggressive ping test (ping -s 1000 -i 0.01) from the application server to the database server—and discovered about 10% packet loss. That explained everything. With traceroute and ping, I quickly located the issue: it was between our data center’s router and our ISP’s switch. In 99% of such cases, the culprit is mismatched duplex settings on the network interfaces.
Our interface was set to auto-negotiate and had settled on 10 Mbps half-duplex. A call to our ISP confirmed that their side was set to 10 Mbps full-duplex. I changed our interface to 10 Mbps full-duplex—and the packet loss disappeared. Instantly, the software system was working again.
I wiped the sweat off my forehead and reflected on the situation. The root cause was that the ISP had not saved the switch configuration we had agreed upon months earlier (auto-negotiation enabled). After the power outage, the switch reverted to the old settings.
I’m lucky to be from a generation of IT professionals with a broad skill set—able to handle all these steps on my own. I can’t imagine a similar problem being resolved efficiently by a team of separate OS admins, DBAs, application developers, and network engineers.
Long live simple systems! I felt like shouting, “WHO CAN POSSIBLY UNDERSTAND ALL THIS?” But we’ll simply have to accept it—and all of us in IT must continuously educate ourselves so we can quickly identify the true causes of problems.
The worst situation is when you don’t know what’s causing an issue and just say, “Well, I guess it’s just something between heaven and earth.”
Original post in Czech, published on June 24, 2006
Ono se řekne fungující aplikace, ale dnešní aplikace, nebo lépe řečeno softwarové systémy, už nejsou tak jednoduché jako v dobách jednouživatelských aplikací v DOSu. Dnes chceme softwarové systémy, které umějí zpracovat velmi mnoho transakcí za sekundu, pracují s nimi stovky nebo ještě lépe tisíce uživatelů, jsou vícevrstvé, integrované z více vzájemně propojených subsystémů těmi nejlepšími integračními nástroji, tím jsou i škálovatelné a robustní. O těchto termínech už jste možná slyšeli, ale kdo se v tom má nakonec vyznat? To aby jste k provozu takovéhoto systému měli tým odborníků. Koho že to vlastně potřebujete? Softwarového architekta, analytika, vývojáře, administrátora operačního systému, databázového administrátora a sítového administrátora. Skvěle, ale to už máte takové měsíční náklady, že to musí být opravdu výtečný obchodní plán, který pokryje režii všech těchto lidí a ještě Vám něco zbyde. Ale i kdyby nakrásně jste takový tým měli, je schopný tento tým rychle a kvalitně odhalit veškeré problémy s provozem systému? Na jednom konkrétním případě se pokusím ukázat, že odhalení nefunkčnosti softwarového systému nemusí být až tak triviální. Pro jednoho zákazníka již léta vyvíjíme a provozujeme online rezervační systém letenek. Systém je rozdělen do několika vzájemně komunikujících vrstev. Vrstva (říkejme jí vrstva 1), která je nejblíže zákazníkovi je klasický webový systém, který pomocí objektově orientovaných technik (dědičnosti), rozšiřuje jednodušší webovou vrstvou (říkejme jí vrstva 2), jenž obsahuje veškerou funkčnost logiky uživatelského rozhraní, ale neobsahuje všechny uživatelské vlastnosti, specifický design, texty a další customizace, které implementuje až vrstva 1. Toto je velmi vhodné hlavně proto, že existuje velké množství customizovaných webů, které fungují nad stejným základem. Obě tyto vrstvy zajišťují pouze grafické uživatelské rozhraní a vlastní rezervační logika je na straně aplikačního serveru (vrstva 3), se kterým vrstva 2 komunikuje pomocí XML přes TCP/IP protokol. Vrstva 3 simuluje práci živého cestovního operátora a snaží se najít v mezinárodním rezervačním systému AMADEUS optimální letecké spoje podle požadavků internetového uživatele. Vrstva 3 tedy komunikuje se systémem AMADEUS pomocí speciálních API funkcí systému AMADEUS přes TCP/IP. Vrstva 3 si však musí pamatovat určité informace a k tomu používá databázový server, se kterým také komunikuje po síti přes protokol TCP/IP. Uznejte, že o tomuto systému už rozhodně nelze mluvit jako o jednoduchém softwarovém systému. Když se na celý systém podíváme z pohledu hardwaru, pak jsou použity minimálně 3 servery. Webový server pro vrstvy 1 a 2, aplikační server pro vrstvu 3 a databázový server.Všechny tyto servery musí být propojeny sítí. A to nemluvíme o serverech systému AMADEUS, které jsou umístěny na druhé straně zeměkoule, ani o případných dalších serverech pro rozdělení zátěže, zálohování, automatické mailování informací o rezervacích, serverech DNS, apod. Celý popis tohoto "poměrně jednoduchého" systému jsem však sepsal proto, abych ukázal, jak není vůbec lehké najít příčinu najednou se objevící závady. Celý systém softwarově vyvíjíme a upravujeme zhruba 5 let a provoz zajišťovala třetí firma, se kterou majitel systému spolupracoval. Asi před rokem se majitel po delší nespokojenosti rozhodl ukončit spolupráci s třetí firmou a požádal nás i o provoz systému. Ten kdo po někom někdy přebíral nějaký informační systém určitě ví, že to rozhodně nění procházka růžovým sadem. Pro nás, jako vývojáře systému to bylo o dost jednodušší, neboť jsme celému systému jako takovému rozuměli, ale i tak se za dobu provozu udělalo na produkčních serverech několik "vylepšení", o kterých nikdo nic moc nevěděl. Naštěstí se povedlo domluvit s bývalým provozovatelem systému, že dojde k postupnému předání serverů a k dodatečné dokumentaci všech "vylepšení". Nebudu zastírat, že postupný převod serverů probíhá již 9 měsíců, ale jelikož systém funguje, tak nebylo zase až tak kam spěchat. Přesun probíhal a probíhá tak, že se vždy připraví nový hardware a vše se úplně znovu nainstaluje. Zároveň se provede upgrade hardwaru, operačního systému i potřebných knihoven. Nicméně již se pomalu dostáváme k pointě celého článku. Jednoho dne systém vypadal tak, že webové servery i aplikační server byly v servrovně bývalého provozovatele a databázový server již byl úspěšně přesunut do naší servrovny. V takovémto stavu systém úspěšně fungoval několik týdnů. V tom volal zákazník a stěžoval si na občasnou nefunkčnost webového rezervačního systému. Po další diagnostice se ukázalo, že systém se občas jeví jako funkční, občas pomalý a občas nefunkční. Po prostudování logů bylo jasné, že problém je mezi aplikačním (vrstva 3) a databázovým serverem. V logu aplikačního serveru se objevovali hlášky o neúspěšných připojeních do databáze. Začal jsem hledat co se v posledních hodinách a dnech se systémem dělo. Den před incidentem jsme nasazovali novější verzi aplikačního serveru. Změny však nebyly nijak velké a rozhodně by neměly mít vliv na spojení do databáze. Nicméně jsme pro jistotu nasadil starší verzi aplikačního serveru. To však nepomohlo. Zaměřil jsem se tedy na prověření funkčnosti databáze. V logu databáze byly záznamy o mnoha neúspěšných pokusech o připojení aplikačního serveru. Po mnoha neúspěšných pokusech databázový server úplně zablokoval možnost připojení z problematického místa. Zaměřil jsem se tedy na zkoumání konfigurace datábáze. Pokusil jsem se zvětšit maximální počet připojených klientů, zvětšit timeout pro připojení klientů a podobné konfigurační parametry. Na problému už jsem celkově trávil asi dvě hodiny a nic z toho nevedlo ke zlepšení situace. V tu chvíli jsem si vzpomněl na týden staré mailové upozornění od našeho ISP, u kterého máme pronajatý rack v servrovně, že budou mít 5ti minutový výpadek v 5:00 hodin ráno. Okamžitě jsem se podíval do mailů a zjistil, že opravdu ten den výpadku byl dnes. Navíc to přesně souhlasilo s časem, kdy se objevily v logu aplikačního serveru první problémy s připojením do databáze. Tomuto mailu jsme sice před týdnem věnovali patřičnou pozornost, ale naše systémy se s podobným výpadkem běžně umí bez problému vypořádat. Navíc náš centrální monitoring systém nehlásil žádný problém. Už asi tušíte, že jelikož byl aplikační server v jiné servorvně než server databázový (u různých ISP), tak to vypadalo na problém síťový. Okamžitě jsem provedl trošku masivnější ping (ping -s 1000 -i 0.01) z aplikačního serveru na databázový a objevila se ztrátovost paketů kolem 10ti procent. V tu chvíli bylo jasno a pomocí utilit traceroute a ping bylo otázkou vteřin identifikovat kde je přesně problém. Problém byl samozřejmě mezi routerem v naší servrovně a switchem našeho ISP. Takovéto problémy má na svědomí v 99% špatně nastavený duplex na síťových rozhraních. Na našem rozhraní byla nastavena autodetekce zdetekovaná na 10Mbps half-duplex a po telefonátu s ISP nám bylo řečeno, že u nich je nastaven 10Mbps full-duplex. Přenastavil jsem tedy nastavení našeho rozhraní na 10Mpbs full-duplex a ztrátovost byla vyřešena. Jako mávnutím kouzelného proutku byl vyřešen i problém s celým softwarovým systémem. V tu chvíli jsem si utřel pot z čela a začal celou situaci hodnotit. Problém zavinil ISP tím, že neuložil na jeho switchi konfiguraci, kterou jsme si před několika měsíci domluvili (auto-negotiation na portu). Po výpadku proudu se samozřejmě nahrálo předchozí nastavení switche. Mám štěstí, že jsem ještě z generace IT lidí, kteří mají široký záběr a všechny popsané postupy si umím zajistit sám. Nedovedu si představit, že by podobný problém řešil administrátor OS, administrátor databáze, programátor aplikačního serveru a nakonec by stejně museli zavolat síťaře. Ať žijí jednoduché systémy! Chce se mi křičet "KDO TOMU VŠEMU MÁ ROZUMĚT!". Nicméně s tím se prostě budeme muset smířit a všichni z IT se neustále vzdělávat, aby jsme byli schopni co nejdříve identifikovat opravdové příčiny problémů. Nejhorší je se dostat do stavu, kdy nevíte čím to může být a říkat sobě i druhým, "JO, TO JE HOLT NĚCO MEZI NEBEM A ZEMÍ".
No comments:
Post a Comment