Herkese merhaba, benim adım Sergey Emelyanchik. Veliam sisteminin ana geliştiricisi ve yazarı olan Audit-Telecom şirketinin başkanıyım. Arkadaşımla nasıl bir dış kaynak şirketi kurduğumuzu, kendimiz için yazılım yazdığımızı ve ardından bunu SaaS sistemi aracılığıyla herkese dağıtmaya başladığımızı anlatan bir makale yazmaya karar verdim. Bunun mümkün olduğuna kategorik olarak nasıl inanmadığım hakkında. Makalede sadece bir hikaye değil aynı zamanda Veliam ürününün nasıl yaratıldığına dair teknik detaylar da yer alacak. Bazı kaynak kod parçaları dahil. Hangi hataları yaptığımızı ve bunları nasıl düzelttiğimizi size daha sonra anlatacağım. Böyle bir makalenin yayınlanıp yayınlanmayacağı konusunda şüpheler vardı. Ancak bunu yapmanın, geri bildirim almanın ve iyileştirmenin, makaleyi yayınlamamaktan ve eğer olsaydı ne olacağını düşünmekten daha iyi olduğunu düşündüm...
tarih öncesi
Bir şirkette BT çalışanı olarak çalıştım. Şirket oldukça büyüktü ve geniş bir ağ yapısına sahipti. İş sorumluluklarım üzerinde durmayacağım, sadece kesinlikle hiçbir şeyin gelişimini içermediğini söyleyeceğim.
Gözlemlerimiz vardı ama tamamen akademik ilgimden dolayı kendi en basit yazımı yazmayı denemek istedim. Fikir şuydu: Web üzerinde olmasını istedim, böylece herhangi bir istemci yüklemeden kolayca girebiliyordum ve Wi-Fi aracılığıyla mobil cihaz da dahil olmak üzere herhangi bir cihazdan ağda neler olduğunu görebiliyordum ve aynı zamanda gerçekten de gerçekten Hızlı bir şekilde ne olduğunu anlamak istedim. Odada "suskun" hale gelen ekipmanlar var çünkü... bu tür sorunlara yanıt verme süresi konusunda çok katı gereksinimler vardı. Sonuç olarak, kafamda, ağ şemasına sahip jpeg arka planının bulunduğu basit bir web sayfası yazmak, bu resimdeki cihazların IP adreslerini kesmek ve dinamik içeriği üstte göstermek için bir plan doğdu. yeşil veya yanıp sönen kırmızı IP adresi şeklinde gerekli koordinatlarda resim. Görev belirlendi, hadi başlayalım.
Daha önce Delphi, PHP, JS ve çok yüzeysel olarak C++ ile programlama yapıyordum. Ağların nasıl çalıştığını oldukça iyi biliyorum. VLAN, Yönlendirme (OSPF, EIGRP, BGP), NAT. Bu benim için ilkel bir izleme prototipi yazmam için yeterliydi.
PHP'de planladığım şeyi yazdım. Apache ve PHP sunucusu Windows'taydı çünkü... O anda Linux benim için anlaşılmaz ve çok karmaşık bir şeydi, daha sonra ortaya çıktığı gibi, çok yanılmışım ve birçok yerde Linux Windows'tan çok daha basit ama bu ayrı bir konu ve hepimiz kaç tane bayram olduğunu biliyoruz. bu konu. Windows görev zamanlayıcısı küçük bir aralıkta (tam olarak hatırlamıyorum ama her üç saniyede bir gibi bir şey) tüm nesneleri sıradan bir ping ile yoklayan ve durumu bir dosyaya kaydeden bir PHP betiğini çekiyordu.
system(“ping -n 3 -w 100 {$ip_address}“);
Evet, evet, o anda bir veritabanıyla çalışmak da benim için usta değildi. Süreçleri paralelleştirmenin mümkün olduğunu bilmiyordum ve tüm ağ düğümlerinden geçmek uzun zaman alıyordu çünkü... bu bir başlıkta oldu. Sorunlar özellikle birden fazla düğümün mevcut olmaması nedeniyle ortaya çıkıyordu, çünkü her biri senaryoyu 300 ms geciktirdi. İstemci tarafında, birkaç saniyelik aralıklarla bir Ajax isteğiyle sunucudan güncellenmiş bilgileri indiren ve arayüzü güncelleyen basit bir döngü işlevi vardı. Peki, arka arkaya 3 başarısız ping'den sonra, bilgisayarda izlemeli bir web sayfası açıksa neşeli bir kompozisyon çalındı.
Her şey yolunda gittiğinde sonuçtan çok ilham aldım ve ona daha fazlasını ekleyebileceğimi düşündüm (bilgim ve yeteneklerim nedeniyle). Ancak milyonlarca grafik içeren sistemlerden her zaman hoşlanmadım ki o zamanlar ve bugün hala çoğu durumda gereksiz olduğunu düşünüyorum. Oraya sadece işimde bana gerçekten yardımcı olacak şeyleri koymak istedim. Bu prensip, Veliam'ın bugüne kadarki gelişiminde temel olmayı sürdürüyor. Ayrıca, izlemeyi açık tutmam ve sorunlar hakkında bilgi sahibi olmam gerekmese ve bu olduğunda sayfayı açıp bu sorunlu ağ düğümünün nerede olduğunu ve bundan sonra ne yapacağımı görmemin çok güzel olacağını fark ettim. . Her nasılsa o zamanlar e-postayı okumadım, kullanmadım. İnternette GET veya POST isteği gönderebileceğiniz SMS ağ geçitlerinin olduğunu ve benim yazdığım metni cep telefonuma SMS göndereceklerini gördüm. Bunu gerçekten istediğimi hemen anladım. Ve belgeleri incelemeye başladım. Bir süre sonra başardım ve şimdi cep telefonuma ağdaki sorunlar hakkında "düşen nesne" adıyla bir SMS aldım. Sistem her ne kadar ilkel olsa da bizzat tarafımdan yazılmıştır ve beni geliştirmeye motive eden en önemli şey işimde gerçekten bana yardımcı olan bir uygulama programı olmasıydı.
Ve sonra İnternet kanallarından birinin iş yerinde çöktüğü gün geldi ve izlemem bana bunu bildirmedi. Google DNS hala mükemmel bir şekilde ping attığından beri. İletişim kanalının canlı olup olmadığını nasıl izleyebileceğinizi düşünmenin zamanı geldi. Bunun nasıl yapılacağına dair farklı fikirler vardı. Tüm ekipmanlara erişimim yoktu. Hangi kanalların canlı olduğunu nasıl anlayacağımızı bulmamız gerekiyordu, ancak bunu bir şekilde ağ ekipmanının kendisinde göremiyorduk. Daha sonra bir meslektaşım, genel sunuculara giden rota izlemenin, İnternet'e erişmek için o anda hangi iletişim kanalının kullanıldığına bağlı olarak farklılık gösterebileceği fikrini ortaya attı. Kontrol ettim ve bu şekilde çıktı. Takip ederken farklı yollar vardı.
system(“tracert -d -w 500 8.8.8.8”);
Böylece başka bir komut dosyası ortaya çıktı veya daha doğrusu, bir nedenden dolayı iz, ağdaki tüm cihazlara ping atan aynı komut dosyasının sonuna eklendi. Sonuçta bu, aynı iş parçacığında yürütülen ve tüm betiğin çalışmasını yavaşlatan başka bir uzun işlemdir. Ama sonra bu o kadar belirgin değildi. Ama öyle ya da böyle işini yaptı; kod, her kanal için ne tür bir izlemenin olması gerektiğini kesin olarak tanımladı. Ağ cihazlarını (yönlendiriciler, anahtarlar, wi-fi vb.) ve dış dünyayla iletişim kanallarını zaten izleyen (yüksek sesle söylendi, çünkü herhangi bir ölçüm koleksiyonu yoktu, sadece ping vardı) sistem bu şekilde çalışmaya başladı. . SMS mesajları düzenli olarak geldi ve şema her zaman sorunun nerede olduğunu açıkça gösterdi.
Dahası, günlük işlerde çapraz geçiş yapmak zorunda kaldım. Hangi arayüzü kullanacağımı görmek için her seferinde Cisco anahtarlarına gitmekten yoruldum. İzleme sırasında bir nesneye tıklayıp açıklamalarıyla birlikte arayüzlerinin bir listesini görmek ne kadar harika olurdu. Bana zaman kazandıracaktı. Üstelik bu şemada hesaplara ve komutlara girmek için Putty veya SecureCRT'yi çalıştırmaya gerek kalmayacak. Sadece izlemeye tıkladım, neye ihtiyaç olduğunu gördüm ve işimi yapmaya gittim. Anahtarlarla etkileşim kurmanın yollarını aramaya başladım. Hemen 2 seçenekle karşılaştım: SNMP veya SSH aracılığıyla anahtara giriş yapmak, ihtiyacım olan komutları girmek ve sonucu ayrıştırmak. Uygulamanın karmaşıklığı nedeniyle SNMP'yi reddettim; sonucu almak için sabırsızlanıyordum. SNMP ile uzun süre MIB'yi araştırmanız ve bu verilere dayanarak arayüzler hakkında veriler oluşturmanız gerekir. CISCO'da harika bir ekip var
show interface statusGeçişler için tam olarak neye ihtiyacım olduğunu gösteriyor. Sadece bu komutun çıktısını görmek istediğimde neden SNMP ile uğraşayım diye düşündüm. Bir süre sonra bu fırsatın farkına vardım. Bir web sayfasındaki bir nesneye tıklandı. AJAX istemcisinin sunucuyla iletişim kurduğu bir olay tetiklendi ve o da SSH aracılığıyla ihtiyacım olan anahtara bağlandı (kimlik bilgileri koda sabitlenmişti, onu hassaslaştırma isteği yoktu, bazı ayrı menüler yapmak için) hesapları arayüzden değiştirmek mümkün olurdu, sonuca ihtiyacım vardı ve hızlı bir şekilde) Yukarıdaki komutu oraya girdim ve tarayıcıya geri gönderdim. Böylece tek bir fare tıklamasıyla arayüzler hakkındaki bilgileri görmeye başladım. Bu, özellikle bu bilgiyi aynı anda farklı anahtarlarda görüntülemeniz gerektiğinde son derece kullanışlıydı.
İzleme tabanlı kanal izlemenin en iyi fikir olmadığı ortaya çıktı çünkü... bazen ağ üzerinde çalışmalar yapılıyordu ve izleme değişebiliyordu ve izleme bana kanalda sorunlar olduğunu bağırmaya başladı. Ancak analize çok zaman ayırdıktan sonra tüm kanalların çalıştığını ve izlememin beni yanılttığını fark ettim. Sonuç olarak, kanal oluşturma anahtarlarını yöneten meslektaşlarımdan, komşuların görünürlük durumu değiştiğinde bana sistem günlüğü göndermelerini istedim. Buna göre takip etmekten çok daha basit, daha hızlı ve daha doğruydu. Komşunun kaybolması gibi bir olay geldi ve hemen kanalın kapanmasıyla ilgili bir bildirim yayınladım.
Ayrıca, bir nesneye tıklandığında birkaç komut daha ortaya çıktı ve bazı ölçümleri toplamak için SNMP eklendi ve temelde hepsi bu. Sistem hiçbir zaman daha fazla gelişmedi. İhtiyacım olan her şeyi yaptı, iyi bir araçtı. Pek çok okuyucu muhtemelen bana internette bu sorunları çözebilecek çok sayıda yazılımın bulunduğunu söyleyecektir. Ama aslında o zamanlar bu tür ücretsiz ürünleri Google'da aratmıyordum ve programlama becerilerimi gerçekten geliştirmek istiyordum ve bunu gerçekleştirmenin gerçek bir uygulama probleminden daha iyi bir yolu olabilir mi? Bu noktada izlemenin ilk versiyonu tamamlandı ve artık değiştirilmedi.
Denetim-Telekom şirketinin kurulması
Zaman geçtikçe başka şirketlerde yarı zamanlı çalışmaya başladım, çok şükür iş programım bunu yapmama izin veriyordu. Farklı şirketlerde çalıştığınızda çeşitli alanlardaki becerileriniz çok hızlı gelişiyor, ufkunuz iyi gelişiyor. İsveçli, orakçı ve trompetçi olduğunuzu söyleyen şirketler var. Bir yandan zordur, diğer yandan tembel değilseniz genelci olursunuz ve bu da ilgili alanın nasıl çalıştığını bildiğiniz için sorunları daha hızlı ve verimli çözmenizi sağlar.
Arkadaşım Pavel (aynı zamanda bir BT uzmanı) sürekli beni kendi işini kurmam için cesaretlendirmeye çalıştı. Yaptıkları şeyin farklı varyasyonlarına sahip sayısız fikir vardı. Yıllardır bu tartışılıyor. Ve sonuçta hiçbir sonuca varmamalıydı çünkü ben şüpheciyim, Pavel ise hayalperest. Ne zaman bir fikir öne sürse, ben ona inanmadım ve katılmayı reddettim. Ama biz gerçekten kendi işimizi açmak istiyorduk.
Sonunda ikimize de uygun bir seçenek bulup nasıl yapılacağını bildiğimiz şeyi yapabildik. 2016 yılında işletmelerin BT sorunlarını çözmelerine yardımcı olacak bir BT şirketi kurmaya karar verdik. Bu, BT sistemlerinin (1C, terminal sunucusu, posta sunucusu vb.) dağıtımı, bunların bakımı, kullanıcılar için klasik Yardım Masası ve ağ yönetimidir.
Açıkçası şirketi kurduğumda buna %99,9 oranında inanmıyordum. Ama bir şekilde Pavel beni denemeye ikna etmeyi başardı ve ileriye baktığımızda haklı olduğu ortaya çıktı. Pavel ve ben kişi başı 300 ruble harcadık, yeni bir LLC "Audit-Telecom" kaydettik, küçük bir ofis kiraladık, harika kartvizitler yaptık, genel olarak muhtemelen çoğu deneyimsiz, acemi iş adamı gibi ve müşteri aramaya başladık. Müşteri bulmak tamamen farklı bir hikaye. Belki ilgilenen olursa kurumsal blogun bir parçası olarak ayrı bir yazı yazacağız. Soğuk aramalar, el ilanları vb. Bu herhangi bir sonuç vermedi. İş dünyası ile ilgili pek çok hikayeyi okuduğuma göre, öyle ya da böyle, pek çok şey şansa bağlı. Şanslıydık. ve kelimenin tam anlamıyla şirketin kurulmasından birkaç hafta sonra kardeşim Vladimir bize yaklaştı ve bize ilk müşteriyi getirdi. Sizi müşterilerle çalışmanın detaylarıyla sıkmayacağım, yazının konusu bu değil, sadece bir denetime gittik, kritik alanları belirledik ve bu alanlar, yapılıp yapılmayacağına karar verilirken bozuldu diyeceğim. dış kaynak sağlayıcıları olarak bizimle sürekli olarak işbirliği yapın. Bunun ardından hemen olumlu bir karar alındı.
Daha sonra, esas olarak arkadaşlar aracılığıyla ağızdan ağza dolaşarak başka hizmet şirketleri ortaya çıkmaya başladı. Yardım masası tek bir sistemdeydi. Ağ ekipmanına ve sunuculara bağlantılar farklıdır veya daha doğrusu farklıdır. Bazı kişiler kısayolları kaydetti, bazıları ise RDP adres defterlerini kullandı. İzleme başka bir ayrı sistemdir. Bir ekibin farklı sistemlerde çalışması çok sakıncalıdır. Önemli bilgiler gözden kayboluyor. Örneğin, müşterinin terminal sunucusu kullanılamaz hale geldi. Bu müşterinin kullanıcılarının başvuruları anında alınır. Destek uzmanı bir istek açar (telefonla alınmıştır). Olaylar ve talepler tek bir sisteme kaydedilmişse, destek uzmanı kullanıcının sorununun ne olduğunu hemen anlayacak ve ona bunu anlatacak, aynı zamanda durumu çözmek için gerekli nesneye bağlanacaktır. Herkes taktiksel durumun farkında ve uyumlu bir şekilde çalışıyor. Bütün bunların birleştiği bir sistem bulamadık. Artık kendi ürünümüzü yapmanın zamanının geldiği belli oldu.
İzleme sisteminiz üzerinde çalışmaya devam ediyoruz
Daha önce yazılan sistemin mevcut görevler için tamamen uygun olmadığı açıktı. Ne işlevsellik ne de kalite açısından. Ve sistemin sıfırdan yazılmasına karar verildi. Grafiksel olarak tamamen farklı görünmesi gerekirdi. Doğru nesnenin doğru müşteriye hızlı ve kolay bir şekilde açılmasının mümkün olabilmesi için hiyerarşik bir sistem olması gerekiyordu. İlk versiyondaki şema mevcut davada kesinlikle haklı değildi, çünkü Müşteriler farklıdır ve ekipmanın hangi tesiste bulunduğu hiç önemli değildi. Bu zaten belgelere aktarıldı.
Yani görevler:
- Hiyerarşik yapı;
- İhtiyacımız olan metrikleri toplayıp merkezi sunucuya göndermek için müşterinin tesislerine sanal makine şeklinde yerleştirilebilecek, tüm bunları özetleyip bize gösterecek bir tür sunucu parçası;
- Uyarılar. Kaçırılmaması gerekenler çünkü... o zamanlar birinin oturup sadece monitöre bakması mümkün değildi;
- Uygulama sistemi. Yalnızca sunucu ve ağ ekipmanlarına değil aynı zamanda iş istasyonlarına da hizmet verdiğimiz müşteriler ortaya çıkmaya başladı;
- Sistemden sunuculara ve ekipmanlara hızlı bir şekilde bağlanabilme yeteneği;
Görevler belirlendi, yazmaya başlıyoruz. Bu arada müşterilerden gelen istekleri işleme koymak. O zamanlar zaten 4 kişiydik. Her iki parçayı da aynı anda yazmaya başladık: merkezi sunucu ve istemcilere kurulum için sunucu. Artık Linux artık bize yabancı değildi ve istemcilerin sahip olacağı sanal makinelerin Debian üzerinde olmasına karar verildi. Kurulumcu olmayacak, yalnızca belirli bir sanal makine üzerinde bir sunucu parçası projesi oluşturacağız ve ardından onu istenen istemciye kopyalayacağız. Bu da başka bir hataydı. Daha sonra böyle bir şemada güncelleme mekanizmasının tamamen gelişmemiş olduğu anlaşıldı. Onlar. bazı yeni özellikler ekliyorduk ve sonra bunu tüm istemci sunucularına dağıtma sorunu ortaya çıktı, ancak buna daha sonra her şey sırayla geri döneceğiz.
İlk prototipi yaptık. İhtiyacımız olan istemci ağ cihazlarına ve sunucularına ping atıp bu verileri merkezi sunucumuza göndermeyi başardı. Ve o da bu verileri merkezi sunucuda toplu olarak güncelledi. Burada sadece nasıl ve neyin başarılı olduğuna dair bir hikaye değil, aynı zamanda hangi amatörce hataların yapıldığını ve bunun bedelini zamanla nasıl ödemek zorunda kaldığımı da yazacağım. Böylece tüm nesne ağacı serileştirilmiş bir nesne biçiminde tek bir dosyada saklandı. Birkaç istemciyi sisteme bağlarken, bazen tamamen anlaşılmaz bazı eserler olsa da her şey az çok normaldi. Ancak bir düzine sunucuyu sisteme bağladığımızda mucizeler gerçekleşmeye başladı. Bazen bilinmeyen bir nedenden dolayı sistemdeki tüm nesneler ortadan kayboluyordu. Burada, istemcilerin merkezi sunucuya POST isteği aracılığıyla birkaç saniyede bir veri gönderdiği sunucuların dikkat edilmesi önemlidir. Dikkatli bir okuyucu ve deneyimli bir programcı, serileştirilmiş nesnenin aynı anda farklı iş parçacıklarından depolandığı dosyaya birden fazla erişim sorunu olduğunu zaten tahmin etmişti. Ve tam da bu olurken nesnelerin ortadan kaybolmasıyla mucizeler meydana geldi. Dosya boşaldı. Ancak tüm bunlar hemen keşfedilmedi, yalnızca birkaç sunucuyla çalışırken keşfedildi. Bu süre zarfında port tarama işlevi eklendi (sunucuların merkeze yalnızca cihazların kullanılabilirliği hakkında bilgi değil, aynı zamanda üzerlerinde açık olan portlar hakkında da bilgi göndermesi). Bu, şu komutu çağırarak yapıldı:
$connection = @fsockopen($ip, $port, $errno, $errstr, 0.5);
sonuçlar genellikle hatalıydı ve taramaların tamamlanması uzun zaman alıyordu. Ping'i tamamen unuttum, fping ile yapıldı:
system("fping -r 3 -t 100 {$this->ip}");
Bu da paralelleştirilemediği için süreç çok uzundu. Daha sonra, doğrulama için gereken IP adreslerinin tam listesi bir kerede fping'e gönderildi ve yanıt verenlerin hazır bir listesini aldık. Bizden farklı olarak fping, süreçleri paralelleştirmeyi başardı.
Bir diğer yaygın rutin iş ise bazı hizmetlerin WEB üzerinden kurulmasıydı. Örneğin, MS Exchange'den ECP. Temelde bu sadece bir bağlantıdır. Belirli bir müşterinin ECP'sine nasıl erişeceğimizi öğrenmek için belgelere veya yer imlerinde başka bir yere bakmak zorunda kalmamak için bu tür bağlantıları doğrudan sisteme ekleyebilmemiz gerektiğine karar verdik. Sistem için kaynak bağlantıları kavramı bu şekilde ortaya çıktı, işlevleri bugüne kadar mevcut ve neredeyse hiç değişmedi.
Veliam'da kaynak bağlantıları nasıl çalışır?
Uzak bağlantılar
Veliam'ın mevcut sürümünde çalışırken böyle görünüyor
Görevlerden biri, zaten çok sayıda (yüzden fazla) bulunan sunuculara hızlı ve rahat bir şekilde bağlanmaktı ve önceden kaydedilmiş milyonlarca RDP kısayolunu sıralamak son derece zahmetliydi. Bir araca ihtiyaç vardı. İnternette bu tür RDP bağlantıları için adres defterine benzer bir yazılım var, ancak bunlar izleme sistemiyle entegre değil ve hesaplar kaydedilemiyor. Her seferinde farklı istemciler için hesap girmek, günde onlarca kez farklı sunuculara bağlandığınızda tam bir cehennemdir. SSH ile işler biraz daha iyi; bu tür bağlantıları klasörler halinde düzenlemenize ve onlardan hesapları hatırlamanıza olanak tanıyan birçok iyi yazılım var. Ama 2 sorun var. Birincisi RDP ve SSH bağlantıları için tek bir program bulamadık. İkincisi, eğer bir noktada bilgisayarımın başında olmazsam ve hızlı bir şekilde bağlanmam gerekirse veya sistemi yeni kurduysam, bu istemciden gelen hesaba bakmak için belgelere gitmem gerekecek. Zahmetlidir ve zaman kaybıdır.
İstemci sunucuları için ihtiyaç duyduğumuz hiyerarşik yapı, dahili ürünümüzde zaten mevcuttu. Orada gerekli ekipmana hızlı bağlantıları nasıl takacağımı bulmam gerekiyordu. Yeni başlayanlar için, en azından ağınız içinde.
Sistemimizdeki istemcinin, bilgisayarın yerel kaynaklarına erişimi olmayan bir tarayıcı olduğu gerçeğini göz önünde bulundurarak, ihtiyacımız olan uygulamayı bir komutla kolayca başlatmak için, her şeyi "Windows" aracılığıyla yapmak için icat edildi. özel URL şeması”. Sistemimiz için, yalnızca Putty ve Remote Desktop Plus'ı içeren ve kurulum sırasında URI şemasını Windows'a kaydeden belirli bir "eklenti" bu şekilde ortaya çıktı. Artık RDP veya SSH aracılığıyla bir nesneye bağlanmak istediğimizde sistemimizde bu eyleme tıkladık ve Özel URI çalıştı. Windows'ta yerleşik standart mstsc.exe veya "eklenti"nin bir parçası olan PuTTY piyasaya sürüldü. Eklenti kelimesini tırnak içine aldım çünkü bu klasik anlamda bir tarayıcı eklentisi değil.
En azından bu bir şeydi. Kullanışlı adres defteri. Üstelik Putty durumunda her şey genel olarak iyiydi; giriş parametreleri olarak IP bağlantıları, kullanıcı adı ve şifre verilebiliyordu. Onlar. Zaten ağımızdaki Linux sunucularına şifre girmeden tek tıkla bağlandık. Ancak RDP ile bu o kadar basit değil. Standart mstsc, kimlik bilgilerini parametre olarak sağlayamaz. Remote Desktop Plus kurtarmaya geldi. Bunun olmasına izin verdi. Artık onsuz yapabiliriz, ancak uzun süre sistemimizde sadık bir yardımcıydı. HTTP(S) sitelerinde her şey basittir; bu tür nesneler tarayıcıda kolayca açılır ve hepsi bu. Kullanışlı ve pratik. Ancak bu yalnızca iç ağda mutluluktu.
Sorunların büyük çoğunluğunu ofisten uzaktan çözdüğümüz için en kolay şey VPN'leri müşterilerin kullanımına sunmaktı. Ve sonra sistemimizden onlara bağlanmak mümkün oldu. Ama yine de biraz rahatsız ediciydi. Her istemci için, her bilgisayarda bir dizi hatırlanan VPN bağlantısını tutmak gerekiyordu ve herhangi birine bağlanmadan önce ilgili VPN'yi etkinleştirmek gerekiyordu. Bu çözümü oldukça uzun süre kullandık. Ancak müşteri sayısı artıyor, VPN sayısı da artıyor ve tüm bunlar zorlanmaya başladı ve bu konuda bir şeyler yapılması gerekiyordu. Özellikle sistemi yeniden yükledikten sonra, yeni bir Windows profilinde düzinelerce VPN bağlantısını yeniden girmek zorunda kaldığımda gözlerimden yaşlar aktı. Buna katlanmayı bırak dedim ve bu konuda ne yapabileceğimi düşünmeye başladım.
Öyle oldu ki, tüm müşterilerin yönlendirici olarak tanınmış Mikrotik firmasının cihazları vardı. Neredeyse her görevi gerçekleştirmek için çok işlevsel ve kullanışlıdırlar. Dezavantajı ise “kaçırılmış olmaları”. Bu sorunu dışarıdan tüm erişimi kapatarak çözdük. Ancak müşterinin evine gelmeden onlara bir şekilde erişebilmek gerekiyordu çünkü... uzun. Her Mikrotik için basitçe tüneller yaptık ve onları ayrı bir havuza ayırdık. herhangi bir yönlendirme olmadan, böylece ağınızın istemcilerin ağlarıyla ve onların ağlarının birbirleriyle bağlantısı olmaz.
Sistemde ihtiyacım olan nesneye tıkladığımda, tüm Mikrotik müşterilerinin SSH hesaplarını bilen merkezi izleme sunucusunun istenen kişiye bağlanmasını, istenen ana bilgisayara bir iletim kuralı oluşturmasını sağlamak için fikir doğdu. gerekli bağlantı noktası. Burada birkaç nokta var. Çözüm evrensel değil - komut sözdizimi tüm yönlendiriciler için farklı olduğundan yalnızca Mikrotik için işe yarayacaktır. Ayrıca, bu tür iletimlerin bir şekilde silinmesi gerekiyordu ve sistemimizin sunucu kısmı esasen RDP oturumumu bitirip bitirmediğimi hiçbir şekilde takip edemiyordu. Böyle bir yönlendirme müşteri için bir deliktir. Ama evrenselliğin peşinde koşmadık çünkü... ürün sadece firmamız bünyesinde kullanılmıştı ve kamuoyuna sunulması gibi bir düşüncemiz yoktu.
Sorunların her biri kendi yöntemiyle çözüldü. Kural oluşturulduğunda, bu yönlendirme yalnızca belirli bir harici IP adresi (bağlantının başlatıldığı adres) için mevcuttu. Böylece bir güvenlik açığının önüne geçilmiş oldu. Ancak bu tür her bağlantıda NAT sayfasına bir Mikrotik kuralı eklendi ve temizlenmedi. Ve herkes bilir ki ne kadar çok kural varsa, yönlendiricinin işlemcisi de o kadar fazla yüklenir. Ve genel olarak, bir gün Mikrotik'e gittiğimde yüzlerce ölü, işe yaramaz kuralın ortaya çıkacağını kabul edemedim.
Sunucumuz bağlantı durumunu takip edemediğinden Mikrotik'in kendisi takip etmesine izin verin. Ve tüm iletim kurallarını belirli bir açıklamayla sürekli izleyen ve TCP bağlantısının uygun bir kurala sahip olup olmadığını kontrol eden bir komut dosyası yazdım. Bir süredir bağlantı kurulmadıysa bağlantı muhtemelen tamamlanmış demektir ve bu yönlendirme silinebilir. Her şey yolunda gitti, senaryo iyi çalıştı.
Bu arada, işte burada:
global atmonrulecounter {"dontDelete"="dontDelete"}
:foreach i in=[/ip firewall nat find comment~"atmon_script_main"] do={
local dstport [/ip firewall nat get value-name="dst-port" $i]
local dstaddress [/ip firewall nat get value-name="dst-address" $i]
local dstaddrport "$dstaddress:$dstport"
#log warning message=$dstaddrport
local thereIsCon [/ip firewall connection find dst-address~"$dstaddrport"]
if ($thereIsCon = "") do={
set ($atmonrulecounter->$dstport) ($atmonrulecounter->$dstport + 1)
#:log warning message=($atmonrulecounter->$dstport)
if (($atmonrulecounter->$dstport) > 5) do={
#log warning message="Removing nat rules added automaticaly by atmon_script"
/ip firewall nat remove [/ip firewall nat find comment~"atmon_script_main_$dstport"]
/ip firewall nat remove [/ip firewall nat find comment~"atmon_script_sub_$dstport"]
set ($atmonrulecounter->$dstport) 0
}
} else {
set ($atmonrulecounter->$dstport) 0
}
}
Elbette daha güzel, daha hızlı vb. yapılabilirdi ama işe yaradı, Mikrotik'i yüklemedi ve mükemmel bir iş çıkardı. Sonunda müşterilerin sunucularına ve ağ ekipmanlarına tek tıklamayla bağlanmayı başardık. VPN açmadan veya şifre girmeden. Sistemle çalışmak gerçekten uygun hale geldi. Servis süresi kısaldı ve hepimiz gerekli nesnelere bağlanmak yerine çalışarak vakit geçirdik.
Mikrotik Yedekleme
Tüm Mikrotik'in FTP'ye yedeklenmesini yapılandırdık. Ve genel olarak her şey yolundaydı. Ancak bir yedek almanız gerektiğinde bu FTP'yi açıp orada aramanız gerekiyordu. Tüm routerların bağlı olduğu bir sistemimiz var, cihazlarla SSH üzerinden haberleşebiliyoruz. Neden bunu sistemin kendisinin tüm Mikrotik'ten günlük olarak yedek almasını sağlayacak şekilde yapmıyoruz, diye düşündüm. Ve bunu uygulamaya başladı. Bağlandık, yedekleme yaptık ve depoya götürdük.
Mikrotik'ten yedekleme almak için PHP'deki komut dosyası kodu:
<?php
$IP = '0.0.0.0';
$LOGIN = 'admin';
$PASSWORD = '';
$BACKUP_NAME = 'test';
$connection = ssh2_connect($IP, 22);
if (!ssh2_auth_password($connection, $LOGIN, $PASSWORD)) exit;
ssh2_exec($connection, '/system backup save name="atmon" password="atmon"');
stream_get_contents($connection);
ssh2_exec($connection, '/export file="atmon.rsc"');
stream_get_contents($connection);
sleep(40); // Waiting bakup makes
$sftp = ssh2_sftp($connection);
// Download backup file
$size = filesize("ssh2.sftp://$sftp/atmon.backup");
$stream = fopen("ssh2.sftp://$sftp/atmon.backup", 'r');
$contents = '';
$read = 0;
$len = $size;
while ($read < $len && ($buf = fread($stream, $len - $read))) {
$read += strlen($buf);
$contents .= $buf;
}
file_put_contents ($BACKUP_NAME . ‘.backup’,$contents);
@fclose($stream);
sleep(3);
// Download RSC file
$size = filesize("ssh2.sftp://$sftp/atmon.rsc");
$stream = fopen("ssh2.sftp://$sftp/atmon.rsc", 'r');
$contents = '';
$read = 0;
$len = $size;
while ($read < $len && ($buf = fread($stream, $len - $read))) {
$read += strlen($buf);
$contents .= $buf;
}
file_put_contents ($BACKUP_NAME . ‘.rsc’,$contents);
@fclose($stream);
ssh2_exec($connection, '/file remove atmon.backup');
ssh2_exec($connection, '/file remove atmon.rsc');
?>
Yedekleme iki biçimde alınır - ikili ve metin yapılandırması. İkili dosya, gerekli yapılandırmanın hızlı bir şekilde geri yüklenmesine yardımcı olur ve metin, ekipmanın zorunlu olarak değiştirilmesi durumunda ve ikili dosyanın ona yüklenememesi durumunda ne yapılması gerektiğini anlamanıza olanak tanır. Sonuç olarak, sistemde başka bir kullanışlı işlevsellik elde ettik. Üstelik yeni Mikrotik eklerken herhangi bir konfigürasyona gerek yoktu, sadece nesneyi sisteme ekleyip SSH üzerinden hesap oluşturdum. Daha sonra sistemin kendisi yedekleme alma işini üstlendi. SaaS Veliam'in mevcut sürümü henüz bu işlevselliğe sahip değil ancak yakında taşıyacağız.
Dahili sistemde nasıl göründüğünün ekran görüntüleri
Normal veritabanı depolama alanına geçiş
Yukarıda eserlerin ortaya çıktığını yazmıştım. Bazen sistemdeki tüm nesne listesi ortadan kayboluyordu, bazen bir nesneyi düzenlerken bilgiler kaydedilmiyordu ve nesnenin üç kez yeniden adlandırılması gerekiyordu. Bu herkesi çok sinirlendirdi. Nesnelerin kaybolması nadiren meydana geldi ve bu dosyanın geri yüklenmesiyle kolayca geri yüklendi, ancak nesneleri düzenlerken hatalar oldukça sık meydana geldi. Muhtemelen başlangıçta bunu veritabanı üzerinden yapmadım çünkü tüm bağlantıları olan bir ağacı düz bir masada tutmanın nasıl mümkün olabileceği aklıma sığmıyordu. Düzdür ancak ağaç hiyerarşiktir. Ancak çoklu erişim ve daha sonra (sistem daha karmaşık hale geldikçe) işlemler için iyi bir çözüm, bir DBMS'dir. Muhtemelen bu sorunla karşılaşan ilk kişi ben değilim. Google'da aramaya başladım. Her şeyin benden önce icat edildiği ve düz bir masadan ağaç oluşturan birkaç algoritmanın olduğu ortaya çıktı. Her birine baktıktan sonra birini uyguladım. Ama bu zaten sistemin yeni bir versiyonuydu, çünkü... Aslında bu yüzden pek çok şeyi yeniden yazmak zorunda kaldım. Sonuç doğaldı, sistemin rastgele davranış sorunları ortadan kalktı. Bazıları, yazılım geliştirme alanında hataların çok amatörce olduğunu söyleyebilir (tek iş parçacıklı komut dosyaları, farklı iş parçacıklarından aynı anda birden çok kez erişilen bilgilerin bir dosyada saklanması vb.). Belki bu doğrudur, ancak asıl işim yönetimdi ve programlama ruhum için bir yan uğraştı ve bu tür temel şeylerin bana kıdemlim tarafından hemen önerildiği bir programcı ekibinde çalışma deneyimim yoktu. yoldaşlar. Dolayısıyla tüm bu tümsekleri tek başıma doldurdum ama materyali çok iyi öğrendim. Ayrıca işim müşterilerle toplantılar, şirketi tanıtmaya yönelik eylemler, şirket içindeki bir dizi idari mesele ve çok daha fazlasını içeriyor. Ama öyle ya da böyle, zaten orada olan şey talep görüyordu. Çocuklar ve ben ürünü günlük çalışmalarımızda kullandık. Açıkçası üzerinde zaman harcanan başarısız fikirler ve çözümler vardı, ancak sonunda bunun işe yarayan bir araç olmadığı, kimsenin kullanmadığı ve Veliam'a varmadığı ortaya çıktı.
Yardım Masası - Yardım Masası
HelpDesk'in nasıl kurulduğundan bahsetmek yanlış olmaz. Bu tamamen farklı bir hikaye çünkü... Veliam'da bu zaten öncekilerden farklı olan 3. tamamen yeni versiyon. Artık basit bir sistem, gereksiz zil ve ıslıklar olmadan sezgisel, bir alan adı ile entegre olma yeteneğinin yanı sıra, bir e-postadan gelen bir bağlantıyı kullanarak aynı kullanıcı profiline her yerden erişme yeteneği var. Ve en önemlisi, başvuru sahibine VNC aracılığıyla herhangi bir yerden (evden veya ofisten), VPN veya port yönlendirme olmadan doğrudan uygulamadan bağlanmak mümkündür. Bu noktaya nasıl geldiğimizi, daha önce yaşananları ve ne korkunç kararların alındığını size anlatacağım.
Tanınmış TeamViewer aracılığıyla kullanıcılarla bağlantı kurduk. Kullanıcılarına hizmet verdiğimiz tüm bilgisayarlarda TV yüklüdür. Yaptığımız ilk yanlış ve daha sonra bunu ortadan kaldırmak, her HD istemciyi donanıma bağlamaktı. Kullanıcı istek bırakmak için HD sistemine nasıl giriş yaptı? TV'ye ek olarak, herkesin bilgisayarında Lazarus'ta yazılmış özel bir yardımcı program yüklüydü (buradaki pek çok kişi gözlerini devirecek ve hatta belki de Google'a soracaktır, ancak bildiğim en iyi derlenmiş dil Delphi'ydi ve Lazarus neredeyse aynı şey, yalnızca ücretsiz). Genel olarak kullanıcı, bu yardımcı programı başlatan özel bir toplu iş dosyasını başlattı; bu dosya, sistemin HWID'sini okudu ve ardından tarayıcı başlatıldı ve yetkilendirme gerçekleşti. Bu neden yapıldı? Bazı firmalarda hizmet verilen kullanıcı sayısı tek tek sayılmakta ve her ay için hizmet bedeli kişi sayısına göre belirlenmektedir. Bu anlaşılabilir bir şey diyorsunuz ama neden donanıma bağlı? Çok basit, bazı kişiler eve gelip evdeki dizüstü bilgisayarlarından “burada her şey benim için güzel olsun” tarzında bir istekte bulundular. Yardımcı program, sistem HWID'sini okumanın yanı sıra, mevcut Teamviewer kimliğini de kayıt defterinden aldı ve bize iletti. Teamviewer'ın entegrasyon için bir API'si vardır. Ve bu entegrasyonu yaptık. Ama bir sorun vardı. Bu API'ler aracılığıyla, kullanıcının bu oturumu açıkça başlatmadığı durumlarda bilgisayarına bağlanması mümkün değildir ve bağlanmayı denedikten sonra "onayla" butonuna da tıklaması gerekir. O zamanlar kullanıcının isteği olmadan kimsenin bağlanmaması bize mantıklı geliyordu ve kişi bilgisayar başında olduğu için oturumu başlatacak ve uzaktan bağlantı isteğine olumlu yanıt verecektir. Her şey yanlış çıktı. Başvuru sahipleri oturumu başlatmak için tuşuna basmayı unuttular ve bunu kendilerine bir telefon görüşmesinde söylemek zorunda kaldılar. Bu zaman kaybıydı ve sürecin her iki tarafı için de sinir bozucuydu. Dahası, bir kişinin istekte bulunduğu ve yalnızca öğle yemeği için ayrıldığında bağlantı kurmasına izin verildiği bu tür anların yaşanması hiç de alışılmadık bir durum değildir. Çünkü sorun kritik değil ve iş sürecinin kesintiye uğramasını istemiyor. Buna göre bağlantıya izin vermek için herhangi bir tuşa basmayacaktır. HelpDesk'te oturum açarken ek işlevsellik bu şekilde ortaya çıktı - Teamviwer'ın kimliğini okumak. Teamviwer'ı kurarken kullanılan kalıcı şifreyi biliyorduk. Daha doğrusu, kurulumcunun ve sistemimizin içine yerleştirilmiş olduğundan bunu yalnızca sistem biliyordu. Buna göre uygulamadan tıklandığında hiçbir şey beklemeye gerek olmayan bir bağlantı butonu vardı ancak Teamviewer hemen açıldı ve bağlantı oluştu. Sonuç olarak iki tür olası bağlantı vardı. Resmi Teamviewer API'si ve kendi hazırladığımız API aracılığıyla. Şaşırtıcı bir şekilde, ilkini kullanmayı hemen bıraktılar, ancak onu yalnızca özel durumlarda ve kullanıcının kendisi onay verdiğinde kullanma talimatı vardı. Yine de bana güvence ver. Ancak başvuranların buna ihtiyacı olmadığı ortaya çıktı. Onay düğmesi olmadan onlara bağlanma konusunda kesinlikle sorun yok.
Linux'ta çoklu iş parçacığına geçiş
Önceden belirlenmiş bir bağlantı noktası listesinin açıklığı ve ağ nesnelerine basit ping işlemi yapılması için bir ağ tarayıcısının geçişini hızlandırma sorunu uzun zamandır ortaya çıkmaya başlamıştır. Burada elbette akla gelen ilk çözüm multithreading oluyor. Ping için harcanan asıl zaman paketin geri dönmesini beklemek olduğundan ve bir sonraki ping önceki paket döndürülene kadar başlayamayacağından, 20'den fazla sunucu ve ağ ekipmanına sahip şirketlerde bu zaten oldukça yavaş çalıştı. Mesele şu ki, bir paket kaybolabilir, ancak sistem yöneticisine bu konuda hemen bilgi vermeyin. Bu tür spam'leri çok çabuk kabul etmeyi bırakacaktır. Bu, erişilemezlik hakkında bir sonuca varmadan önce her nesneye birden fazla kez ping atmanız gerektiği anlamına gelir. Çok fazla ayrıntıya girmeden paralelleştirmek gerekiyor çünkü bu yapılmazsa, büyük olasılıkla sistem yöneticisi sorunu izleme sisteminden değil istemciden öğrenecektir.
PHP'nin kendisi çoklu iş parçacıklarını kullanıma hazır olarak desteklemez. Çoklu işlem yapabilme yeteneğine sahip, çatallayabilirsiniz. Ama aslında, zaten yazılmış bir yoklama mekanizmam vardı ve bunu veritabanından ihtiyacım olan tüm düğümleri saymak, her şeye aynı anda ping atmak, her birinden yanıt beklemek ve ancak bundan sonra hemen yazmak için yapmak istedim. veri. Bu, okuma isteklerinin sayısından tasarruf sağlar. Çoklu iş parçacığı bu fikre mükemmel bir şekilde uyuyor. PHP için, gerçek çoklu iş parçacıklarını kullanmanıza izin veren bir PThreads modülü vardır, ancak PHP 7.2'de bunu ayarlamak oldukça fazla incelik gerektirdi, ancak yapıldı. Bağlantı noktası tarama ve ping artık hızlı. Ve örneğin tur başına 15 saniye erkene almak yerine bu süreç 2 saniye sürmeye başladı. İyi bir sonuçtu.
Yeni şirketlerin hızlı denetimi
Çeşitli metrikleri ve donanım özelliklerini toplama işlevi nasıl ortaya çıktı? Basit. Bazen bizden sadece mevcut BT altyapısını denetlememiz isteniyor. Yeni bir müşterinin denetimini hızlandırmak için de aynı şey gereklidir. Orta veya büyük bir şirkete gelip, neye sahip olduklarını hızlı bir şekilde anlamamızı sağlayacak bir şeye ihtiyacımız vardı. Benim düşünceme göre, iç ağdaki ping yalnızca kendi hayatlarını zorlaştırmak isteyenler tarafından engelleniyor ve deneyimlerimize göre bunlardan çok azı var. Ama böyle insanlar da var. Buna göre, basit bir ping ile ağları cihazların varlığı açısından hızlı bir şekilde tarayabilirsiniz. Daha sonra bunları ekleyebilir ve bizi ilgilendiren açık portları tarayabiliriz. Aslında, bu işlevsellik zaten mevcuttu; belirtilen ağları taraması ve bulduğu her şeyi listeye eklemesi için merkezi sunucudan ikincil sunucuya bir komut eklemek yeterliydi. Söylemeyi unuttum, bir denetim sırasında istemciden kolayca çıkarabileceğimiz ve bulutumuza bağlayabileceğimiz yapılandırılmış bir sisteme (slave izleme sunucusu) sahip hazır bir görüntümüzün zaten olduğu varsayılmıştı.
Ancak bir denetimin sonucu genellikle bir sürü farklı bilgi içerir ve bunlardan biri ağda ne tür cihazların olduğudur. Öncelikle bir etki alanının parçası olarak Windows sunucuları ve Windows iş istasyonlarıyla ilgilendik. Orta ve büyük şirketlerde alan adı eksikliği muhtemelen kuralın bir istisnasıdır. Bir dili konuşmak için ortalama 100'den fazla kişi olduğunu düşünüyorum. Tüm Windows makinelerinden ve sunucularından, IP'lerini ve etki alanı yöneticisi hesaplarını bilerek, ancak her birine herhangi bir yazılım yüklemeden veri toplamanın bir yolunu bulmak gerekiyordu. WMI arayüzü kurtarmaya geliyor. Windows Yönetim Araçları (WMI), kelimenin tam anlamıyla Windows yönetim araçları anlamına gelir. WMI, Windows platformunu çalıştıran bilgisayar altyapısının çeşitli bölümlerinin çalışmasının merkezi olarak yönetilmesi ve izlenmesi için temel teknolojilerden biridir. Wiki'den alınmıştır. Daha sonra, Debian için wmic'i (bu bir WMI istemcisidir) derlemek için tekrar uğraşmam gerekti. Her şey hazır olduktan sonra geriye kalan tek şey, gerekli bilgiler için wmic aracılığıyla gerekli düğümleri yoklamaktı. WMI aracılığıyla bir Windows bilgisayarından hemen hemen her bilgiyi alabilirsiniz ve dahası, bilgisayarı onun aracılığıyla da kontrol edebilirsiniz, örneğin onu yeniden başlatmaya gönderebilirsiniz. Sistemimizdeki Windows istasyonları ve sunucuları hakkındaki bilgilerin toplanması bu şekilde ortaya çıktı. Buna ek olarak güncel sistem yükü göstergelerine ilişkin güncel bilgiler de yer aldı. Bunları daha sık, donanımla ilgili bilgileri ise daha az talep ediyoruz. Bundan sonra denetim biraz daha keyifli hale geldi.
Yazılım dağıtım kararı
Biz de sistemi her gün kullanıyoruz ve her teknik çalışana her zaman açık. Ve sahip olduklarımızı başkalarıyla paylaşabileceğimizi düşündük. Sistem henüz dağıtıma hazır değildi. Yerel sürümün SaaS'a dönüşmesi için birçok şeyin yeniden işlenmesi gerekiyordu. Bunlar, sistemin çeşitli teknik yönlerindeki değişiklikleri (uzaktan bağlantılar, destek hizmeti), lisanslama modüllerinin analizini, müşteri veritabanlarının parçalanmasını, her hizmetin ölçeklendirilmesini ve tüm parçalar için otomatik güncelleme sistemlerinin geliştirilmesini içerir. Ancak bu makalenin ikinci kısmı olacak.
Güncelleme
Kaynak: habr.com